정의의소의 블로그

테스트는 누가해야 하는가?를 읽고...

(정의의소) — Mon, 04 Feb 2008 00:23:41 +0900

TestCrunch에 올라온 "테스트는 누가해야 하는가?"에 대한 트랙백을 위한 글 입니다.

Nikkei Electronics 2007년 4월 23일 자에 나온 "공들여 만드는 소프트웨어, 검증하기 쉬운 설계로"라는 제목의 자료에도 나오는 그림 중에 이런 말이 있습니다.

" 아니 이렇게 테스트하기 어렵게 설계하면 어떻게 해요!"
- 테스터

아직 우리나라 대부분의 업체에서는 테스터가 이렇게 이야기 할 수 있는 곳은 없을 것입니다.

"아니 이렇게 생산하기 어렵게 설계하면 어떻게 해요!"
- 생산담당자

생산하기 힘드니 다시 설계하라는 이야기를 하는 곳은 있을 수도 있을 겁니다.
생산을 고려해서 설계를하고 개발하라는 것입니다.

Application/Game 개발자분들은... 디자이너분들과 이런 이야기 자주 나누지 않습니까?

"이런 디자인/컨셉은 개발하기 힘들다... 당신들이 개발을 안해봐서 그런가 본데... 이건 너무 힘들어요..."
- 개발자

테스트도 개발의 한 부분이고 중요하다는 것을 개발자가 더 잘 알고 있을 것입니다.
그러나 오랜 관습과 바쁘다는 현실에서 변화하기가 쉽지 않은 것 같습니다.

개발자 테스트하면 자주 등장하는 TDD는 테스트보다는 Design적인 측면이 더 중요하게 생각되는 것 같습니다.
Test Driven Development 보다는 Design의 의미가 강하다고 생각됩니다.
TDD에 의해서 모든 테스트가 끝나지 않습니다. TDD는 품질에 대한 최소한의 요구사항이라고 생각합니다.

“Clean code that works!"
- Test Driven Devlopment 에서 Kent Bect

TDD는 분석/설계 도구이지 테스트 도구가 아닙니다. TDD를 통해서 얻는 Code Coverage는 TDD의 목적이 아니라고 생각됩니다. 부수적인 이득이라고 봐야겠죠.
TDD의 궁극의 목적은 "Clean Code That Works"라고 봅니다.

테스트를 위하여 API 뿐만 아니라, 시스템 전체를 고려한 설계와 개발이 이루어지고 함께 테스트가 진행되어야 더욱 빠른 개발을 할 수 있다고 생각합니다.

애자일 소프트웨어 개발 선언문

(정의의소) — Mon, 28 Jan 2008 13:11:18 +0900

새로운 과제를 시작하면서 Remind 차원에서 다시 정리해 봅니다.

우리는 직접 개발하면서도 또 남이 개발하는 일을 도와주면서 소프트웨어 개발의 더 나은 방법을 발견하고 있다. 이 작업을 통해 우리는 아래 것들을 가치 있게 여기게 되었다.

'프로세스와 도구'보다는 '개인과 상호작용'을
'포괄적인 문서화'보다는 '동작하는 소프트웨어'를
'계약 협상'보다는 '고객과의 협력'을
'계획 준수'보다는 '변화에 대응'을
이 말은, 욎쪽에 있는 것들에도 가치가 있긴 하지만, 우리는¹ 오른쪽에 있는 것들에 더 많은 가치를 둔다는 것이다.

© 2001, 애자일 선언 입안자들

더 많은 정보는 http://agilemanifesto.org/를 참고하세요.
- Practices of an Agile Developer 中...

null [Back]

[Ship it] Tip 조언 요약

(정의의소) — Thu, 24 Jan 2008 20:11:59 +0900

"Ship It 성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드"를 다시 읽었습니다.

새로 시작하는 과제에 개발과 함께 SCM, Process, SQE를 담당하기로 하였습니다.
Scrum 적용부터 제가 하고 싶은 것을 함께 적용할 기회를 가지게 되었습니다.
팀원들에게 어느 정도 호응도 얻었습니다. ^,.^;

그래서 과제를 진행하는데 있어 몇 가지 정리할 것이 있어 Ship It을 다시 읽게 되었습니다. 그래서 부록에 있는 Tip 조언 요약을 정리해 봅니다. 아래의 글에서 나중에 글들이 링크될 수 있습니다. 어떻게 인프라와 프로세스를 구축했고 어떻게 팀원들을 설득했으며 어떤 문제로 어려워하고 있는지를 이 글을 기준으로 시작하려고 합니다.

앞으로 재발행될 요지가 큰 포스트입니다.ㅎㅎ

- TIP 조언 요약 -

습관을 고르세요.
모래 상자 안에 머무세요.
필요한 거라면 체크인하세요.
첫날에 빌드를 스크립트화 하세요.
어떤 컴퓨터에서라도 빌드가 되어야 합니다.
지속적으로 빌드하세요.
지속적으로 테스트하세요.
모두가 잊어버리는 사태는 피해야 합니다.
제품을 작동시켜보세요 - 테스트를 자동화하세요.
유연하고 많은 사람이 사용하는 테스트 장비를 사용하세요.
업무에 가장 적합한 도구를 사용하세요.
공개된 포맷을 사용해서 여러 도구를 통합하세요.
임계 경로 기술에 친숙해지세요.
목록에 따라 일하세요.
기술 리더가 알아서 하게 놔두세요.
일일 회의를 해서 진행 방향을 수시로 바로 잡으세요.
"나중에"라고 말해도 됩니다.
항상 모든 코드를 재검토하세요.
소프트웨어가 목표지, 순응이 목표는 아닙니다.
그룹 전체가 아키텍트입니다.
제품에서 사용하는 거라면, 여러분도 사용해야 합니다.
가장 어려운 문제부터 해결하세요.
캡슐화된 아키텍처야말로 확장성 있는 아키텍처입니다.
보트가 움직이기 전엔 보트를 조정할 수가 없습니다.
테스트하기 전에는 다른 사람이 물려준 코드를 변경하지 마세요.
테스트 주도 리팩토링으로 테스트할 수 없는 코드를 깨끗이 정리하세요.
가짜 클라이언트로 최소한의 노력으로 최대의 성과를 거둘 수 있습니다.
변경되는 코드를 지속적으로 테스트하세요.
모두에게 통하는 방법이어야 합니다.
자주 통합하고, 지속적으로 빌드하고 테스트하세요.
동작하는 데모를 일찍 그리고 자주 전달하세요.
여러분이 무엇을, 왜 하고 있는지 공개하세요.
얼굴을 많이 마주칠수록 팀워크가 단단해집니다.
고쳐야 하는 것만 고치세요.
파괴적인 '우수한 업무처리기법'은 진정한 의미의 업무처리기법이라 할 수 없습니다.
밑에서부터 혁신해야 합니다.
말만 하지 말고 보여주세요.
관리층의 지지를 이끌어내세요.
버그가 있는 곳을 테스트하세요.
목록은 살아있는 문서입니다. 변화가 목록의 생명입니다.
목록에 없다면, 그것은 프로젝트 일부가 아닙니다.
항상 피드백을 빨리해 주세요.

제주도 가족 여행 사진

(정의의소) — Fri, 18 Jan 2008 01:43:25 +0900

지난 10월 제주도 가족 여행 사진 입니다.

선별없이 전체 사진을 용감하게 켜켜켜...

‘행위의 중복’을 없애는, 사람을 위한 자동화

(정의의소) — Sat, 12 Jan 2008 09:28:59 +0900

프로젝트를 진행함에 있어 가장 중요한 요소 중의 하나가 자동화라고 생각합니다.

IBM developerWorks의 자동화 관련된 내용을 오픈마루 강규영님께서 정리해 주셨네요.

진행하고 있는 프로젝트와 비교해 보시고 적용 점을 찾아 보시면 많은 도움이 있을 것 같습니다.

제가 올해 부터 진행하는 프로젝트에 하나 씩 적용하면서 어떻게 적용하였고 어떤 장,단점이 있는지를 정리하려고 합니다.

인프라(툴), 프로세스, 테스트(기법)의 내용이 주된 내용이 될 것 같습니다.

똘똘하게 일합시다.(Work smart) ^,.^;

more..

필자 | 강규영, 엔씨소프트 오픈마루 스튜디오 웹서비스 개발팀 alankang@openmaru.com

2007년 10월 30일
2008년 01월 08일 수정

어느 정도 경험이 있는 개발자라면, 혹은 마틴 파울러의 "리팩토링"을 읽어본 개발자라면, 소스 코드 중복이 왜 문제이며 중복을 어떻게 하면 효과적으로 제거할 수 있는지 잘 알고 있을 것입니다. 하지만 제거해야 할 중복은 소스 코드에만 있는 것이 아닙니다.

소프트웨어를 빌드할 때마다 반복적으로 입력하는 명령어들, 코드를 수정한 후 수동으로 수행하는 반복적 테스트, 주기적으로 작성하는 각종 리포트 등은 소스 코드 중복은 아니지만 "행위의 중복"이며 제거해야 할 대상입니다.

이 연재는 다양한 자동화 기법을 통해 이러한 "행위의 중복"을 제거하는 효과적이고 검증된 방법들을 상세히 설명합니다. 이를 통해 반복적이고 지루한 작업은 컴퓨터에 떠넘기고, 여러분은 더 창의적이고 가치 있는 일에 집중할 수 있게 될 것입니다.

1편: 빌드 스크립트에서 나는 “악취(smell)” 제거하기 (한글)

2편: 연속 테스팅 (한글)

3편: Eclipse 플러그인으로 코드 품질 높이기 (한글)

4편: Continuous Integration 서버 선택하기 (한글)

5편: Continuous Inspection (한글)

6편: 지속적인 피드백 (한글)

7편: 아키텍처 건전성 (한글)

8편: Raven으로 자바 프로젝트 구현하기 (한글)

9편: Continuous Integration 반패턴(anti-pattern) (한글)

TEXTCUBE 1.6 Beta1을 설치하고 나서 생기는 문제

(정의의소) — Thu, 03 Jan 2008 23:20:58 +0900

아래와 같이 버그 리포팅은 했는데...
아무런 답글도 대응도 없네요... ^^;
다음 패치를 기다려야 하나?

해결 방법 없을까요?

1.6 Beta 1을 설치하고 나서 아래와 같은 문제가 있습니다.
http://dicawoo.com/blog 로 들어가면 Bad Request가 나옵니다.
http://dicawoo.com/blog/ 로 들어가면 정상적으로 들어 오구요.
확인 부탁드립니다.

올해 하고 싶은 프로젝트?

(정의의소) — Tue, 01 Jan 2008 21:38:30 +0900

올해는 어떤 일을 하게 될까요?

최근 4년 동안 테스트라는 큰 업무는 비슷하지만 매년, 반기, 분기 별로 하는 업무가 달랐던 것 같습니다.

내일 출근 하면 부서장님과 면담을 통해서 하고싶은 일을 설득해 보려고 합니다.

하고 싶다고 다 할 수 있는 것은 아니지만 꼭 그렇게 하고 싶습니다. 저는 그게 정말로 필요하다고 생각하고 있습니다.

거창한 것은 아니고,

- Process
- Tool
- Organization(Role)

을 Integration 하려고 합니다.

Process는 사내 Process에 Agile(Lean, Scrum)을 접목 시키고
Tool은 회사 내 툴 및 Opensource를
Organization은 보다 Role이 명확하고 Communication이 잘 될 수 있게

이미 많은 책과 사례가 나와 있지만 제가 근무하는 회사에 알맞는 것을 찾아 보려고 합니다.
내일 아니면 이번주에 부서장님과 이야기 나눠보고 생각하는 이야기를 올려 보겠습니다.
첫 시작 부터 하나 하나 구성해 나가는 것을 하나의 카테고리에 정리해 보려고 합니다.

적어도 매 분기 별로 조직의 Role이 바뀌었는데(크게는 아니더라도) 또 모르죠 조직 발표가 나면 어떤 일을 하게 될지... ^,.^;

상대방을 인정하지 못하면 나도 패한다.

(정의의소) — Thu, 20 Dec 2007 00:05:35 +0900

1달 동안 쉬었던 블로그를 오늘 부터 다시 시작합니다.

그 분을 인정하겠습니다. 그건 제가 지지 않기 위함입니다.

거위의 꿈

(정의의소) — Mon, 19 Nov 2007 23:41:59 +0900

97년 군대에 있을 때 였던가 카니발의 "그 땐 그랬지"가 참 유행을 했었다.

그 앨범에 함께 있었던 노래가 '거위의 꿈'이었다.
최근에 인순이씨가 다시 이 노래를 부르는 것을 보았다. 디지털 싱글 앨범을 내고 1위까지 했다고 한다.

최근 마음에 변화가 있어서 그런가 꿈에 대해 생각하면 많은 아쉬움과 희망이 교차한다.
꿈이 맘 속에서 꿈틀 거린다... 꿈틀... 꿈틀... 아...

글을 쓰면서도 가슴이 뛴다... 왜 일까?

<인순이 '거위의 꿈>

<카니발 '거위의 꿈>

[Flash] http://serviceapi.nmv.naver.com/flash/NFPlayer.swf?vid=93F5E1EBF9A16EBC584C8880C6DFA2B1982A&outKey=01050aac1db62c13a09cc2bc6994ba315e6bb71d20f6184c08a8797b2165dae8dd6a512574a260ea2f69fa93631c7d00

- 거위의 꿈

난 난 꿈이 있었죠. 버려지고 찢겨 남루하여도
내 가슴 깊숙히 보물과 같이 간직했던 꿈

혹 때론 누군가가 뜻 모를 비웃음 내 등 뒤에 흘릴 때도
난 참아야 했죠 참을 수 있었죠 그 날을 위해

늘 걱정하듯 말하죠 헛된 꿈은 독이라고
세상은 끝이 정해진 책처럼 이미 돌이킬 수 없는 현실이라고

그래요 난, 난 꿈이 있어요 그 꿈을 믿어요 나를 지켜봐요
저 차갑게 서 있는 운명이란 벽 앞에 당당히 마주칠 수 있어요

언젠가 난, 그 벽을 넘고서 저 하늘을 높이 날을 수 있어요
이 무거운 세상도 나를 묶을 순 없죠
내 삶의 끝에서 나 웃을 그 날을 함께 해요

늘 걱정하듯 말하죠 헛된 꿈은 독이라고
세상은 끝이 정해진 책처럼 이미 돌이킬 수 없는 현실이라고

그래요 난, 난 꿈이 있어요 그 꿈을 믿어요 나를 지켜봐요
저 차갑게 서 있는 운명이란 벽 앞에 당당히 마주칠 수 있어요

언젠가 나 그 벽을 넘고서 저 하늘을 높이 날을 수 있어요
이 무거운 세상도 나를 묶을 순 없죠
내 삶의 끝에서 나 웃을 그 날을 함께 해요

좋은 팀장과 서번트 리더십

(정의의소) — Mon, 19 Nov 2007 02:08:22 +0900

제임스님의 "훌륭한 엔지니어가 좋은 팀장이 되기 어려운 이유"를 읽고 서번트 리더십에 대해서 다시 한 번 생각해 봅니다.

팀장이 가져야하는 역량은 크게 두 가지로 나눌 수 있다고 생각합니다.
- 기술을 리딩할 수 있는 능력
- 감성을 움직일 수 있는 능력

서번트 리더십 이란?
공동의 최선을 위해 설정된 목표를 향해 매진할 수 있도록 사람들에게 영향력을 발휘하는 기술인 동시에 사람들의 신뢰를 형성하는 인격
-서번트 리더십 실전매뉴얼편에서..

너희 중에 리더가 되고자 하는 사람은 먼저 봉사자가 되어라...
남을 이끌려면 봉사하는 법부터 깨우쳐야 하느니.
- 예수 그리스도

고압적인 권력의 가치와 그 효과는 역비례 관계에 있다.
- 로버트 그린리프

기술적인 리딩뿐만 아니라 감성적인 리딩을 통해서 모든 팀원들이 행복해 하며 모든 프로젝트가 성공적으로 마칠 수 있기를 기원합니다.
이 세상의 모든 팀장님들 힘내세요~ 화이팅 입니다.