인수테스트, 북치고 장구치고 2/2
팀장의 고백 목차
- 게으른 PL이 프로젝트 일정을 지연시킨다.
- 개발명세서? 그 귀찮은 짓을 왜 하지?
- 개발계획은 팀장의 것? 팀원의 것?
- 팀장! 당신은 진정한 Nego를 할 수 있는가?
- 형상 관리, 그까이거 그냥 폴더에 보관하면 되지 1부
- 형상 관리, 그까이거 그냥 폴더에 보관하면 되지 2부
- Trac을 통한 품질 관리
- UnitTest! 미완의 시도
- 인수테스트, 북치고 장구치고 1/2
- 인수테스트, 북치고 장구치고 2/2 (오늘의 post)
- 진정한 프로젝트의 가치는 어디에서 오는 것일까?
지난 post에서 테스트를 해야 하는 이유를 간단히 살펴 봤습니다. 그럼 이번 post에서는 다양한 테스트 중에서 인수테스트의 의미와 효용성을 살펴 보겠습니다. 인수 테스트를 처음 들어 보신 분들을 위해서 인수 테스트의 정의를 간단히 알아보고 넘어 가겠습니다. 인수테스트란 “개발된 시스템이 고객의 요구사항과 일치하는지 확인하기 위해서 고객 주관으로 수행하는 테스트”를 뜻합니다. 간단히 정의한다고 했는데, 다소 복잡한거 같습니다. 조금 더 쉽게 정의하면… 고객이 말한대로 시스템을 만들었는지, 고객이 직접 테스트하는 것을 인수 테스트라고 합니다.
XP에서는 인수테스트를 다음과 같이 보고 있습니다.
고객 소유의 인수 테스트를 마련하지 못하는 것은 XP에서 가장 흔한 실수 중 하나입니다. 매 반복(iteration)마다 고객에게 인수 테스트 정의를 받도록 하세요. 고객이 그 테스트들을 정의하도록 도와주세요 - 조언을 해주세요. 그 테스트들을 구현하고, 바라는대로 시스템이 작동한다는 것을 고객에게 보여주세요. 고객은 더 나은 테스트와 더 나은 기능을 만드는 법을 배우게 될 것이고, 프로젝트에 참가하는 모두가 당신이 어디쯤 있는지 알게 될 겁니다. 인수 테스트를 작성할 도구를 기다리지 마세요. 다른 여타의 프로그램이나 테스트들처럼 그냥 프로그램하세요. 그 도구들이 시간이 지남에 따라 진화하도록 하세요. 중요한 것은 바로 테스트를 갖는 것입니다. 서문 from XP Installed 론 제프리 외 2명 공저(인사이트)
XP에서 iteration을 끌고 나가는 것이 Story Card라면 인수테스트는 주기의 끝을 알리는 결승점의 깃발과 비슷합니다. 따라서 귀찮은(?) 인수테스트를 매 주기마다 적용하기 위해서 자동화된 툴을 도입할 것을 주장합니다. XP다운 사상이죠.
물론 여러분들은 현업에서 XP를 적용할 수도 있고 안할 수도 있습니다. 마찬가지로 CMM을 적용할 수도 있고 적용 안할 수도 있습니다. 심지어 프로세스 규정집이라고 부를 수 있는 A4용지 한 장조차도 없을 수 있습니다. 그러나 어떤 개발환경이나 어떤 프로세스를 사용하더라도 실천해야 하는 몇가지 practice가 있습니다. 제가 post하고 있는 팀장의 고백 시리즈의 소주제들이 이런 practice가 될 수 있습니다. 마찬가지로 인수테스트도 이 practice에 포함됩니다.
인수테스트와 관련된 업계의 현실을 설명드리겠습니다.
(특히 SI 프로젝트인 경우) 모든 프로젝트는 고객의 요구에서 시작합니다. 빅뱅이 우주의 시작이었던 것처럼요. 그러나 SI 프로젝트가 처해 있는 상황을 보면 “내 시작은 미약했으나 그 끝은 창대하리라!”가 아니고 “내 시작은 창대하였으나 그 끝은 미약하리라!”라는 생각이 듭니다. 고객의 요구 사항은 너무나 화려합니다. 요구 사항의 구현 가능성을 의심하는 것은 민족을 반역하는 행위처럼 프로젝트에서 받아 들여집니다. 그렇기 때문에 고객이 말한 요구 사항은 시나리오로 작성되고, 개발 명세서라는 예쁜 문서로 꾸며지고, 솔거도 울고 갈만큼 진짜 GUI와 비슷한 화면 설계서로도 그려집니다.
그리고 멀고도 먼 구현의 대장정을 떠납니다. A4 용지로 출력된 개발 명세서는 몇번이나 읽었는지 기억이 나질 않습니다. 그리고 어느새 개발 명세서는 입시 공부할 때 사용했던 참고서보다 더 많은 밑줄과 동그라미가 긋어집니다. 물론 열심히 공부 했다고 시험 점수가 잘 나오지 않는 것처럼, 수많은 야근과 특근으로 채워진 일정표가 프로젝트의 성공을 보장해 주지 않습니다. 또한 화려한 설계서와 개발 명세서도 프로그램이 성공적으로 만들어졌는지를 보장해 주지 않습니다. 아니 어느 누구도(고객을 포함해서) 완성된 프로그램이 고객의 요구사항을 만족시키는 것이라고 말해주지 않습니다.
다만 몇 번의 사용자 설명회에서 핵심 고객에게 프로그램(시스템)을 완성했고, 사용해 보라고 설명합니다. 그리고 몇 번의 이벤트만 잘 넘어가면 프로젝트는 끌날거라고 생각합니다. 그러나, 가끔은 순진하고 순수한 고객은 완성된 프로그램(시스템)을 보고 본인이 얘기한 게 아니라고 말합니다. 고객의 갑작스런 변덕에 벼랑 끝에 내몰린 개발자는 개발 명세서, 화면 설계서, 시나리오를 보여주면서 “고객님이 O월 O일에 이렇게 만들어 달라고 하셨습니다.”라고 반박합니다. 그러나 순진하지만 한편으로 꾀가 많은 고객은 “그 버튼을 눌렀을 때 이렇게 이렇게 되야한다고 말했는데, 고객 요구 명세서에는 이렇게 이렇게 만들어야 한다고 적지 않으신거 같은데요.”라고 말합니다.
해맑게 웃고 있는 고객의 얼굴을 보고 있자니, 거짓은 아닌거 같습니다. 자! 이제부터 프로젝트 2막의 시작입니다. 다시 고객의 요구 사항을 정리해서 이번에는 완벽히 만들어야겠네요… 재미 있게 하려고 약간의 과장을 섞었지만, 현실과 큰 괴리가 있는 이야기는 아닙니다. 우리는 고객의 요구사항을 받아 적는데는 어느 정도 수준에 올라와 있습니다. 하지만 요구 사항이 구현되었을 때, 이것을 어떻게 검증할까에 대해서는 아직 초보 수준인거 같습니다. 물론 어떤 분들은 “고객의 요구사항=인수 테스트”라고 주장하실 수 있지만, 이 둘은 남극과 북극이 둘 다 지구에 있는 곳이지만 지리적으로 멀리 떨어져 있는 것처럼 명백히 다릅니다.
둘 사이의 차이점에 대해서 조금 더 설명을 하자면… 고객의 요구 사항과 인수 테스트는 자유 여신상을 바라본 다른 두 화가가 그린 그림처럼 다른 그림입니다.(물론 오브제가 같지만요.) 즉, 고객 요구 사항은 자유의 여신상의 특징적인 인상을 묘사한 인상파 그림이라면, 인수 테스트는 자유의 여신상에 묻은 때까지 정밀하게 묘사해 놓은 초정밀화라고 볼 수 있습니다. 그렇기 때문에 그림이라는 범위에서 고객 요구 사항과 인수 테스트를 보시는 분들은 그냥 그림이라고 하실 수 있지만, 조금 더 관심을 기울이시는 분들에게는 고객 요구 사항과 인수 테스트는 다르며 그 나름 존재 의미가 있습니다.
이 정도로 인수 테스트의 의미에 대해서 이야기를 마치고, 인수 테스트의 효용성에 대해서 알아보겠습니다. 테스트의 효용성이 품질 향상이듯이, 인수 테스트의 일차적인 효용성도 품질 향상입니다. 인수 테스트를 작성하고 작성된 인수 테스트에 맞추어서 테스트를 진행한 후, 발생한 문제점을 수정하면 당연히 프로그램의 품질은 높아집니다. 이건 너무나도 당연한 이야기겠죠. 이것만으로도 인수 테스트를 해야 하는 목적이 분명합니다. 하지만 저는 인수 테스트를 하는 목적이 품질향상 외에 한가지 목적이 더 있다고 생각합니다. 인수 테스트는 프로젝트의 끝을 알리는 (정치적) 깃발 역할을 합니다.
인수 테스트 작성 주체는 고객입니다. 물론 인수 테스트를 작성할 때 프로젝트 팀에서 도와주기는 하지만, 인수 테스트는 고객이 생각하는 요구 사항 만족 기준입니다. 그렇기 때문에 인수 테스트는 고객의 것입니다. 따라서 고객이 작성한 인수테스트를 이용해서 테스트를 끝마쳤다는 뜻은 프로젝트가 완료되었다는 의미입니다. 따라서 이후의 고객의 요구는 완료된 프로젝트 밖의 요구 사항입니다. 반대로 인수 테스트를 하지 않은 경우에는, 모든 요구 사항을 개발했다고 말해도 완료되었다고 주장할 수 있는 자료가 없기 때문에 추가되는 고객의 요구 사항은 프로젝트 범위에 포함됩니다.
제가 이야기 드리는 인수테스트의 효용성은 다소 정치적인 면이 있습니다. 살아 있는 생물체처럼 항상 변하는 고객의 요구를 통제하고 한정된 자원으로 프로젝트 결과를 이끌어야 하는 팀장 입장에서 정치를 외면할 수도 없습니다. 그래서 인수테스트를 작성하는 것이 그나마 프로젝트를 옳은 방향으로 이끌어 갈 수 있는 합리적인 정치 수단이리고 생각합니다. 물론 인수테스트를 작성했다고 해서, 고객의 요구사항은 한마디로 거절할 수도 없습니다. 그러나, 인수테스트와 같은 자료는 정치 판단의 근거를 감정인 아닌 이성의 영역으로 옮겨 놓기 때문에, 고객과 요구사항을 두고 줄다리기를 할 때 기분 좋은 협상을 할 수 있습니다.
반대로 이런 인수테스트를 작성하지 않는다면 명확한 근거가 없기 때문에, 요구사항의 반영 여부는 자칫 잘못하면 감정의 문제로 흐를 수 있습니다. 즉, 프로젝트 팀에서는 “우리는 할 도리를 다 했습니다. 너무 하시는거 아닙니까?” 고객의 입장에서는 “아! Hani 팀장 쫀쫀하게 굴지 말고 이거 하나만 더 해죠.” 이런 식의 협상은 쫀쫀함과 뻔뻔함의 대결이 되기 때문에 요구하는 입장이나 요구받는 입장이나 감정적으로 상하게 됩니다. 이런 이유때문에 인수 테스트는 작성해야 합니다.
지금부터는 이번 프로젝트에서 인수 테스트를 어떻게 작성했고 어떤 결과를 얻었는지 살펴 보면서, 오늘의 post를 마치겠습니다. 일단 제목에서 암시하듯이 이번 프로젝트의 인수 테스트는 제가 작성했습니다. 고객이 다른 업무로 너무나 바쁜 상황이여서… 할 수 없이 제가 작성했습니다. 물론 작성은 제가 했지만, 최종적인 검토는 고객에게 맡겼습니다. 고객이 새로운 내용을 첨가하거나 빼서 인수 테스트를 완성했습니다. 이번 프로젝트에서 인수 테스트를 작성한 이유는 outsourcing 때문입니다. resource를 회사안에서 활용하는 상황이라면 고객의 요구 사항을 한 두가지 더 들어 주는 것은 문제가 아니었으나, outsourcing을 하도 보니 반드시 모듈의 개발 완료를 확정지어야 했습니다.
인수 테스트 케이스, 약 220여 항목의 테스트 케이스를 작성했음
작성된 인수 테스트는 프로젝트 시작 시에 협력업체에 전달되었고, 업체는 인수 테스트와 개발 명세서를 활용해서 개발을 진행했습니다. 모듈 개발 후에 몇가지 추가적인 개발이 있었지만, 인수 테스트를 작성해서 고객의 요구가 명확히 반영되었기 때문에 고객과 업체 사이에는 큰 이슈가 없었습니다.(다행이죠! 
)
이상으로 오늘의 post를 마치고, 다음은! 드디어! 팀장의 고백 시리즈의 마지막 편입니다. 기대해 주세요!