한 동안 블로그를 안하다보니 책 리뷰를 쓰는게 참 오랜만입니다. 그 동안 이런 저런 책들을 많이 읽었는데 차마 리뷰를 할 시간도, 그런 것을 고민할만한 여유도 없었네요. (정말 지난 회사 같은 곳은 다시는 안갈려구요.)
'조대협의 소프트웨어 개발'이라는 블로그를 운영하시는 조대협님이 「소프트웨어 개발과 테스트」라는 책을 출간하였습니다.
ActiveX 없는 간편 결재를 제공하는 알리딘으로 책 사러가기
http://www.aladin.co.kr/shop/wproduct.aspx?ISBN=8965400937
평소에도 관심있게 종종 지켜봐오던 블로그였고, 가끔 테스트에 대한 통찰력 있는 글들을 올리시는 분이셨기 때문에 책이 나온다는 소식을 들었을 때 무척 들떴습니다. 나오기도 전에 예약 주문을 해서 지난 주 금요일에 받았습니다. 그런데 주말 내 감기 때문에 골골 대다가 몇 일 뒤 읽기 시작했습니다. 출퇴근 시간과 점심 시간을 이용해서 약 3일 정도의 시간 동안 읽어내려갔네요.
이 책은 소프트웨어 개발과 관련된 담론과 테스트에 대한 개발자적인 방향을 잘 제시해주고 있는 책입니다. 일반적인 이해를 돕기 위한 이야기들을 차례대로 읽고 있노라면 조대협님이 평소에 (남들은 이론일 뿐이라 치부하거나, 자신이 경험한 것만 집중하는) 개발방법론에 대해 얼마나 치열하게 실무에 녹여 내려 고민하는 지 잘 드러납니다.
본 글을 본격적으로 시작하기 전에 아래와 같이 등장 인물들을 정의하고 가려합니다.
- 저자 = 조대협
- 필자 = 천년나무
필자는 이 책의 감상평을 여러분들게 이렇게 전하고 싶습니다.
"소프트웨어 개발을 업으로 삼으신 분들 중, 소프트웨어 품질 측면의 시야를 넓히고 아키텍트로서의 삶을 꿈꾸시는 분들은 반드시 읽어봐야 할 필독서. 하지만 소프트웨어 테스트 전문가, 품질전문가를 꿈꾸는 사람들에게는 비추천."
이 책의 가장 큰 장점은 저자의 경험에 기반하여 소프트웨어 개발 공정 중에 발생하는 여러가지 문제들에 대한 저자의 문제 인식과 통찰력을 잘 풀어 냈다는 점입니다. 그 중 몇 가지 저자가 제공하는 문제 인식은 읽는 사람으로 하여금 매우 공감하며 고개를 끄덕이게 합니다. 제가 가장 큰 공감을 했던 부분은 대한민국 소프트웨어 시장에 정상적인 역량을 가진 품질관리자가 많지 않고, 제대로 된 테스트 리드가 부족하며, 이는 프로젝트의 진행 로그 관리에 실패하기 때문이라는 부분이었습니다. 필자는 이 부분에 격렬히 공감합니다. 프로젝트에서 한 명이 모든 프로젝트 로그를 기록하고 관리할 수 없기 때문에 각 개발 이해관계자들이 모두 협업해야 하는데, 대한민국 사람들은 이상할 정도로 자신이 했던 일들을 잘 기록하지 않는 듯 합니다. (어째서인지 경력이 많은 분들 조차도 자신이 한 일을 자신이 직접 증명하는 활동이 자신이 할 일이 아니라고 생각하더군요.)
또한 이 책에서는 저자가 직접 경험하고 회고하여 얻은 교훈들이 잘 녹아 있습니다. 필자가 읽으며 가장 공감했던 또 다른 부분은 바로 '운영 환경 배포 시에는 수동이 더 안전하다'는 저자의 표현이었습니다. 이런 부분은 실제로 해 보지 않으면 절대 쉽게 말할 수 없는 소중한 경험 공유이다보니 필자는 이 부분을 읽으면서 저자와 뭔가로 이어지는 듯한 느낌 조차 받았습이다. 대부분의 자동화 도구 컨설턴트들은 도구만 도입하면 개발 환경부터 운영 배포까지 다 자동화 된다고 말하지만, 필자 역시 실제 업무를 할 때 시스템의 복잡도가 높을 수록 (특히 하드웨어와의 연계가 높을 수록) 수동 배포가 훨씬 많은 시간을 절약할 수 있음을 경험했기 때문에 저 부분을 읽을 때 짜릿한 무언가가 와 닿았던 듯 합니다.
필자가 이 책을 대한민국의 모든 개발 이해관계자들에게 필독서로 권하고 싶은 이유는, 저자가 소프트웨어 개발 영역 전체에서 발생할 수 있는 테스트들에 대한 개념적인 설명을 포괄적으로 잘 전개해 두었기 때문입니다. 특히 요새는 그냥 「리뷰 회의」로 통일되어 버린 「전통적인 방식의 정적 분석」 인 리뷰 방법들에 대한 개념 설명은 매우 유용합니다. 필자가 평소에 개발팀에 설명하려 엄청 애쓰는 부분인데, 이제 이 책을 통해 필자의 수고를 덜 수 있게 될 듯 합니다.
하지만 품질관리자 입장에서 조금 냉철히 평가하자면 이 책은 소프트웨어 개발의 전 영역을 아우르는 테스트 전문서로 보기에는 조금 무리가 있습니다. 품질관리자인 필자 입장에서 평 하자면 '딱 프로그래머들을 위한 테스트 책'입니다. 일단 저자가 소프트웨어 프로그래머 관점으로 책을 기술하였고, 책을 읽고 있노라면 개발 부서의 장 혹은 아키텍트의 입장인 누군가가 후배 프로그래머에게 노하우를 알려주듯 조곤조곤 개념을 설명하고 있습니다. 하지만 그렇기 때문에 소프트웨어 공학적인 관점으로 보기엔 설명이 모자란 느낌을 받게 됩니다. 소프트웨어 테스트나 품질에 대한 국제 표준이나 기-존재하는 연구 결과, 다른 테스트 서적의 내용이나, 다른 테스트 전문가들의 통찰은 참조되지 않았기 때문입니다.
그렇기 때문에 필자는 이 책을 소프트웨어 공학이 아닌 소프트웨어 개발을 위해 테스트를 설명한 책이라 평하고 싶습니다. 하지만 분명히 이 책은 대한민국의 많은 프로그래머들에게 필독서로 권하고 싶은 책입니다. 프로그래밍은 굉장히 논리적으로 하고서도 테스트는 막무가내로 하고 있는, 필자가 만나온 수 많은 프로그래머들에게 '소프트웨어 테스트란 이런 것이란다'라고 이 시대의 개발 전문가가 말해주는 책이기 때문입니다.
다시 한 번 강조하지만, 테스트를 주 업으로 삼고 품질관리자를 꿈꾸는 사람들에게는 이 책을 추천하고 싶지 않습니다. 소프트웨어 Tester들과 QA들은 소프트웨어 테스터 카페에서 제공하는 비-정기적인 세미나에 참석하시는 쪽이 품질에 대한 시야를 넓히는 데에 더 도움이 되실겁니다.
< 그림 출처 - PAKINFO360 >
앞서 언급한 바와 같이 이 책은 정확히는 Developer를 위한 책이고 Engineer를 위한 Engineering 도서는 아닙니다. 이렇게 말하는 이유는 필자가 이 책을 읽으며 몇 가지 불편함을 느꼈고 이유를 찾아 냈기 때문인데, 그 중 하나는 '개발 용어'와 '공학 용어'가 혼재되어 사용되고 있다는 점입니다. 이는 저자가 책의 서문에서 밝힌 바와 같이 평소에 연재하던 블로그의 글들을 편집하는 과정에서 발생한 현상으로 보입니다. 그 중 몇 가지를 짚어 보겠습니다.
1. 컴포넌트의 정의
용어의 혼재가 두드러지는 부분은 3장과 4장인데, 저자는 ISTQB를 소개하면서도 6장에서 '컨포넌트' 개념을 정확히 짚어주지 않았습니다. 컴포넌트는 개발 관점과 공학 관점에서 각기 다른 단위(Unit)로 표현됩니다.
저자가 3장에서 소개한 ISTQB에서는 컴포넌트를 "독립적으로 테스트 될 수 있는 최소 소프트웨어의 항목(A minimal software item that can be tested in isolation)"이라고 정의합니다. ISTQB 자격증 공부를 하다보면 컴포넌트는 "다른 모듈에 의존성을 가지지 않고 독립적으로 작동하는 단위 모듈"이라고 풀이됩니다. 하지만 프로그래머 영역에서의 컴포넌트는 클래스들의 모음, 혹은 컨테이너를 의미합니다. SDK에서 표현되는 구조상 그렇게 읽히는 것이 컴포넌트이고, 읽히는 대로 이해하는 것이 프로그래밍시에는 직관적이고 쉽기 때문입니다. 그래서 프로그래머들이 말하는 컴포넌트와 테스터들이 말하는 컴포넌트는 면멸히 따지자면 단위의 크기가 다릅니다.
컴포넌트 이야기가 나왔으니 하나 더 사족을 달자면, 우리가 흔히 「단위 테스트」에 대해 말하지만 사실 단위(Unit)의 크기는 이 세상에 표준이 없습니다. 각 회사에 맞게, 각 제품에 맞게 정의하면 됩니다. 때로는 시스템 하나가 단위가 될 수도 있고 컴포넌트가 될 수도 있으며, 단위 기능 하나 혹은 단위 모듈 하나 혹은 GUI의 엘레멘트 하나도 단위라고 부를 수 있습니다. 이를 결정하는 것은 전적으로 테스트를 분석하고 수행할 테스트 담당자의 몫입니다.
2. 방법론 vs 접근 방법 vs 프레임워크
이 책에서 저자가 계속 혼용하는 부분은 바로 "방법"과 "프레임워크"인데, 저자는 하나의 표현으로 "방법" 혹은 "방법론"이라고 표현합니다. 그런데 필자는 이 3가지의 구별에 굉장히 민감한 편입니다. 어떻게 정의하느냐에 따라 조직 구성원들의 시야가 달라지고, 조직의 문화가 달라지는 것을 많이 경험했기 때문입니다. 개인적으로 필자는 애자일과 스크럼에 대해서도 다음과 같이 정의합니다.
"애자일은 방법론이 아님. 애자일은 철학과 접근방법만 제공."
"스크럼은 방법론이 아닌 프레임워크라 표현하는 것이 옳음. 스크럼에서는 애자일-스러운 접근을 위해 팀이 지켜야할 규약을 제공하기 때문."
소프트웨어 공학을 업으로 삼지 않으시는 분들에게는 이런게 말 장난으로 느껴질 수도 있으니 조금 더 실생활에 가까운 설명을 곁들여 봅니다. 만약 우리가 "불을 켜는 방법을 안다" 라고 말하는 것과, "불을 켜기 위한 접근 방법에는 무엇 무엇이 있다" 라고 말하는 것과, "불을 켜기 위한 프레임워크는 이런 것들이 있다" 라는 세 가지 다른 의미의 말을 마구 혼용한다면 우리는 불 하나 켜는 데에도 극심한 혼돈을 겪을 것입니다. 그런데 이상할 정도로 소프트웨어 개발방법론과 프레임워크 부분에 있어서 우리들은 이 표현들을 마구 혼용해서 사용하고 있음을 발견하게 됩니다. 그리고 본 책에서도 비슷한 현상이 발생하고 있습니다.
필자가 단언컨데 소프트웨어 공학에서는 용어의 정의가 굉장히 중요합니다. 왜냐하면 소프트웨어의 특성상 여러 도메인의 지식들이 합쳐져 하나의 제품으로 융합되는 성격이 있기 때문에 용어 정리를 명확히 한다는 행위 자체가 요구사항을 분석하는 첫 단계입니다. 실무에서 통용되는 용어를 '유두리 있게' 이해해서는 절대 소프트웨어의 요구사항은 명확해지지 않습니다. 필자는 소프트웨어 공학을 40년 가까이 하신 지도 교수님과 종종 소프트웨어 테스트나 품질에 대해 이야기를 나누는데, 그럴 때마다 교수님과 저는 서로 대화 도중 용어 정리를 한 번 하고 이야기를 이어나갑니다. 같은 소프트웨어 공학을 하는 사람들끼리도 공학을 적용하는 도메인에 따라 용어의 의미를 다르게 사용하기 때문입니다.
3. ISTQB는 방법론인가 프레임워크인가?
ISTQB는 소프트웨어 개발에서 발생할 수 있는 일반론적인 소프트웨어 테스트 프레임워크를 제공합니다. ISTQB에서는 '이렇게 테스트하면 된다' 라는 테스트 방법을 제공하지 않습니다. 다만 '이런 상황에서는 이런 활동들을 이런 식으로 하면 된다' 라는 프레임워크만을 제공합니다. 그런데 저자는 이 책에서 ISTQB에 대해 '테스트 방법을 제공한다'라는 표현을 합니다. 이 책의 전체 부분에서 "방법" 과 "프레임워크" 라는 두 단어를 혼용하여 사용하기 때문에 읽다보면 불편함이 느껴지는데 이 부분도 그 중 하나입니다.
4. QA는 Test가 아니다.
필자가 블로그를 통해 이미 여러번 비슷한 이야기를 서로 다르게 주장했었습니다.
이 포스팅을 빌려 언급하건데, 필자가 실무를 진행하면서 제일 듣기 혐오스러워하는 말 중 하나는 바로 "QA하다" 라는 말입니다. "QA 했니?", "QA 해야지"... 대체 'QA를 한다'는 것이 무슨 의미인지 잘 모르겠는데, 거의 모든 회사에서 이런 용어를 사용하고 있습니다. 언제, 어느 때부터 우리는 Test라는 말의 대용으로 QA라는 말을 사용하게 된 것일까요?
또, 왜 대한민국에서는 Test팀을 테스트팀이라 부르지 못하고 QA팀이라고 부르는 걸까요? 대부분의 QA팀들은 QA활동을 전혀하고 있지 않고, 테스트 활동에 집중하고 있는데 말입니다. 개발 환경의 이름도 'QA환경' 이라 부르는 것도 참 우습습니다. 'Test환경'이라고 부르면 없어보인다고 생각하는 것일까요? QA와 Test는 전혀 다른 활동인데, Test라는 말 대신 QA라는 용어를 쓰는 것은 대한민국 공통적인 현상이며, 「테스트」를 설명하는 본 책에서도 같은 방식으로 사용하고 있어 품질관리자인 필자 입장에서는 씁쓸함을 감출 수 없었습니다.
실무에서 그렇게 사용하고 있기 때문에 이 책에서도 QA = Test로 표현된듯 합니다. 필자의 입장에서는 답답하지만, 인식이 넓게 퍼진 것에 맞서 싸우고 싶지 않기에 언젠가 고쳐지기를 기다려야 겠습니다.
5. 그 외
이 외에도 용어가 혼재되어 사용되는 부분들이 있다보니 앞 뒤의 내용이 용어의 잘 못된 사용으로 헷갈리는 경우도 있습니다. 3장에서는 성능엔지니어가 통합단계에서 테스트를 한다고 설명하고서, 4장에서는 테스트팀에서 비기능테스트의 일종으로 성능테스트를, 개발팀에서 통합테스트를 한다고 설명되어 있는 부분도 있습니다. 테스트를 기반으로한 품질전문가로서 필자의 의견을 피력하자면, 사실 통합테스트든 뭐든 테스트에는 딱히 롤(Role)을 정하지 않는 것이 좋습니다. 테스트 결과라는 것은 일반적으로 책임 소재의 문제로 귀결되기 때문입니다. 이에 자세한 이야기는 다음 기회에 하도록 하시죠.
그런데 성능엔지니어는 뭐 하는 역할일까요? 대부분 PaaS 환경에서의 성능테스트는 개발자들이 진행하지만, 그것은 성능테스트를 너무 쉽게 생각하기 때문에 그렇습니다. 사실 성능테스트는 개발+테스트+네트워크+시스템성능이라는 굉장히 특별한 분야입니다. 여러분들의 회사가 In-house SaaS 구조를 가지고 있거나, In house PaaS 구조를 가지고 있다면 반드시 필요한 엔지니어입니다. 하지만 일반적으로 쉽게 구할 수 있는, 시장에 흔하디 흔한 엔지니어가 아니며, 때로는 QA직군으로 분류되기도 하지만 개발자 이상의 연봉을 지불하셔야 하는 특별한 사람들입니다.
< 그림 출처 - CanStock Photo >
필자 입장에서 테스트 전문 서적을 보다보니 아쉬운 점이 많습니다. 또 하나는 본 책이 지나칠 정도로 개발 부서의 수장, 혹은 아키텍트의 관점에서 쓰여진 책이라는 점입니다. 이번에는 이런 부분들 중 몇 개를 찾아 사족을 달아 볼까 합니다.
1. 스크럼에서 QA의 역할
대부분의 스크럼 프레임워크를 적용한 팀들은 폭포수 개발방법론에서 말하는 바를 개선하려 애자일의 접근방법을 도입하였음에도 불구하고, 일반적으로 스크럼에서 QA의 역할을 폭포수 개발방법론과 같은 방향으로 가져갑니다.
결론적으로 말하건데 스크럼 도입 후 QA를 V&V(Verification & Validation)으로 쓰는 것은 낭비입니다. 일단 Iteration의 Item들을 구현하고 검증하는 데에는 뛰어난 Test Engineer가 필요 없고, 그렇다보니 자연스레 상대적으로 값 싼 인력을 사용하게 됩니다. 하지만 싼 인력은 Engineer라고 보기에는 무리가 있어 개발팀과 동화되지 못하고 계속 V&V의 활동만 하게 됩니다. (이곳에서 V&V 활동이 무엇인지에 대해 설명하지는 않겠습니다.)
이런 문제를 급진적으로 타개한 접근방법이 있는데, 그 방법은 리사 크리스핀이 저술한 "애자일 테스팅"이라는 책에 소개되어있습니다. 지금 이 글을 쓰는 필자 역시 이 방법으로 QA팀원을 BA(Business Analyst) 역할로 사용하여 성공했던 사례도 있습니다. 본 책에서 저자가 기술했다시피 스크럼에서는 PO(Product Owner)가 주요 사업에 대한 의사결정을 진행하게 됩니다. 특히 심각한 점은 프로젝트가 완료되어 운영으로 넘어간 후 개발자가 할 수 없는 많은 사업적 의사결정 사항이 PO에게 집중되면서 PO의 의사결정이 개발의 Bottleneck으로 나타나게 되는데, 이런 경우 대부분 초기 도출한 User story가 작성 당시에는 명확치 않기 때문에 피드백을 주고 받는 과정에서 감추어졌던 요구사항을 알게 되어 이를 해결하기 위한 의사결정이 발생하는 경우가 대부분입니다. 그리고 이런 문제를 해결할 수 있는 방안이 바로 V&V 활동을 하는 QA들이라 할 수 있습니다.
왜냐하면 QA들은 항상 제품 공정의 마지막 단계에서 제품의 변화를 감지하면서 일을 하기 때문에 좋든 싫든 한 제품에서 1년 정도가 지나면 감각적으로, 그리고 직관적으로 형상관리를 (무의식적으로) 하고 있게 됩니다. 여러분들 회사의 QA들이 다른 회사보다 더 심하게 투덜거리는 것이 아니라, 수치화 되지 않은 데이터가 그들의 머리 속에서 직관적으로 위험신호를 보내고 있기 때문에 투덜거리고 있는 것입니다. 이를 조금만 직관적으로 데이터화하면 PO의 사업 의사결정을 효율적으로 도울 수 있습니다. QA들이 받는 위험 신호의 근원을 파헤쳐 직관적인 데이터화하는 것은 결코 시간 낭비가 아닙니다. (일례로 이 활동은 VOC가 들어오기 전에 VOC를 예방할 수 있는 절호의 찬스이기도 합니다.)
또한 V&V 활동이라는 것 자체가 요구사항을 기반으로 진행될 수 밖에 없기 때문에, 업무 수행 중 User story에 대해 가장 많이 고민하고 업무에 활용하는 역할 역시 QA들 입니다. 그렇기 때문에 PO가 초기 작성한 명확치 않은 User story를 가장 효율적으로 업그레이드할 수 있는 사람 역시 그 제품의 프로젝트에서 오랜 동안 경험을 쌓은 QA라 할 수 있습니다. (그리고 이런 친구들을 BA로 키워 PO를 돕거나, PO 역할을 확장할 수 있습니다.) 이런 식으로 실제 업무에서는 경험이 쌓인 QA들에게 User story를 작성하게 하고, QA들이 작성한 User story를 기반으로 개발자들에게 개발하게 하면 가장 TDD스러운 개발 접근 방식이 될 수 있습니다.
2. 분석/설계의 강점
저자는 1장에서 "1:1:1 법칙" 이라는 섹션을 통해 "분석/설계, 구현, 테스트"가 각기 1분할 되어야 한다고 소개하였습니다. 하지만 필자의 경험상 사람이라는 것이 타성에 쉽게 젖는 동물이다보니, 실제로 팀을 효율적으로 개선하고 실무에 방법론을 적용하기 위해서는 분석/설계에 실제 개발 투입 기간의 50% 이상 투입해야 합니다. 단순히 1:1:1로 해 두어서는 다른 업무에 비해 어려운 분석/설계에 집중하지 않는 경향이 무의식적으로 나타나 조직 문화에 뿌리뻗기 때문입니다. 필자가 주장하는 분석/설계에 투자하는 50% 이상의 시간에는 구현담당자들에게 공유하는 시간을 포함해야 합니다. 특히 DB의 형상에 영향을 주는 모듈을 개발할 경우에는 반드시 모든 개발자들에게 분석/설계 내용을 (그들이 관심 있건 없건) 공유해야 합니다. DB와 SP(Stored procedure)의 형상에 의존성을 가지는 모듈이 많아지면 많아 질 수록, 이후 필연처럼 찾아드는 Refactoring의 난이도에 영향을 주기 때문입니다.
이 부분에 대해 필자는 NIPA에서 근무 중이신 윤OO 수석님과 이에 대해 짧게 이야기를 나누었는데 윤 수석님의 말씀으로는 "스크럼에서는 원래 분석/설계, 구현 도중에 (상호 토론과 피드백 등으로) 테스트 활동이 단계마다 끼어 있다고 볼 수 있기 때문에 1:1:1로 해도 크게 상관 없다. 그리고 원래 분석/설계 분야가 대한민국에서 약했었기 때문에 1:1:1이라고 해도 예전보다는 많이 나을 것이다." 라는 의견을 주셨습니다. 필자도 이에 동의합니다. 윤 수석님은 2012년 NIPA에서 진행했던 사업을 하나 알려주시기로 하셨는데, NIPA 조사에 따르면 분석/설계에 70%가까이를 투자한 SI Project가 가장 큰 내부/외부 만족도를 보였으며, 사업도 성공한 케이스가 있다고 합니다. (자료가 오면 블로그에 참조하여 내용 추가할 예정.)
3. PMBOK과 다른 내용
저자는 애자일 섹션에서 프로그램 매니저, 프로젝트 매니저와 PMO를 설명하면서 국제 표준인 PMBOK의 내용과 다르게 설명한 내용이 있어 이 부분에 대해서도 사족을 달아볼까 합니다.
일단 PMBOK의 제일 앞에서 주요하게 설명하는 프로젝트(Project)와 운영(Operation)의 차이부터 살펴보아야 합니다. 프로젝트란 고유한 제품, 서비스 또는 결과물을 창출하기 위해 한시적으로 투입하는 노력이며, 운영은 사업의 영속을 위해 제품을 유지보수하고 관리하는 활동이라 할 수 있습니다.
PMBOK에서는 크게 「포트폴리오 vs 프로그램 vs 프로젝트」로 나누어 설명합니다. 포트폴리오는 조직의 목표 달성을 위해 프로젝트 혹은 프로그램의 우선순위를 결정하고, 조직의 전략적 관점에서 위험과 기회를 관리하는 것이며, 프로그램은 상호관련된 프로젝트의 모음을 뜻합니다.
또, PMO(Project Management Office)는 조직 목표를 달성하고, 전사 자원의 활용을 최적화, 위험관리, 프로세스 관리, 방법론 관리를 하는 역할로 조직에 활용합니다. 조직 내에서 PMO는 크게 지시형(Directive)와 지원형(Supportive)로 나눌 수 있습니다.
4. 테스트의 4단계
소프트웨어 테스트는 공학적 관점에서 크게 4가지 분류로 나눌 수 있습니다. 이는 「단위, 통합, 시스템, 인수」입니다. 저자는 이 4가지의 테스트 단계를 테스트 방법이라는 식으로 표현하고 있습니다. 그리고 인수테스트에 대해 개략적으로 고객관점의 테스트 정도로 설명하고 있습니다.
이 테스트의 4단계는 필자가 예전에 애자일 관련 포스팅을 하면서 설명을 올린 적이 있으니 그곳을 참고해주세요. 인수테스트는 사실은 계약서 기반의 테스트라 할 수 있습니다. 계약을 하는 당사자의 요구사항을 명확히 하는 방법일 수 있고, Gold Plating되지 않도록 하기 위한 장치일 수도 있습니다.
마지막으로, 테스트케이스 개발을 구현이라 표현해 준 것은 저자에게 매우 고마운 마음을 전하고 싶습니다. 프로그래머에게 프로그래밍이 구현이듯, 테스터에게는 테스트케이스 개발이 구현입니다. 그런데 자꾸 테스트 강의하시는 분들이 테스트케이스 작성을 「설계」라 칭하다보니 실무를 하는 테스터들을 설득시키기가 여간 힘이 듦니다. 테스트 하는 사람들에게는 테스트케이스 작성이 구현이며, 이를 행하는 것이 수행임을 강조하고 싶네요.
글이 꽤 길었습니다. 이 외에도 이런 저런 부분들이 전문적인 품질관리자 입장에서 책을 읽기에는 불편하거나, 사족을 달고 싶은 부분들이 많았습니다. 하지만 이 책은 분명히 모든 소프트웨어 개발담당자들이 알고 있어야 할 소프트웨어 테스트에 대한 포괄적인 이야기를 담고 있어, 마지막으로 다시 프로그래머의 필독서로써 추천하며 글을 마치려 합니다.
언제가 조대협님과 책의 내용을 소재로 이야기를 할 기회가 있기를 빌며.
