인수테스트 기반의 회사운영
제 회사에서는 의외로 단위 테스트에 대한 강제 규정이 없습니다.
단위 테스트는 개발 방법론이나 개발자가 개발 프로세스와 관련되어 작성하는 건 어쩌면 당연합니다만 언제나 그렇듯이 문제는 무언가 강제화한다는 점에 있습니다.
특히 강제화에서 끝나지 않고 평가기준이 되면 단위테스트는 곧 코드커버리지와 결합하여 과업을 증명하는 용도로 쉽게 악용됩니다. 우리는 개발자이므로 일단 이 트리를 타게 되면 쉽게 이것을 악용할 수 있는 개발을 하게 됩니다. 하지만 이건 개발자이 잘못이 아니라 평가 등의 개인의 영달과 관련된 시스템이 그것을 유도한다고 할 수 있습니다(오너인 제 경험으로는 거의 100%로 사측이 유도한거라 생각합니다)
이런 점에서 저는 사내의 개발 상태를 평가하거나 개인이 개발완료라고 보고하는 부분에 단위테스트를 전혀 고려하지 않고 단위테스트는 본인들이 개발시 추구해야하는 자율적인 옵션으로 봅니다.
그러면 어떻게 개발 공정을 측정할까요? 개발 시 저희는 다음과 같은 단계로 진행합니다.
- 기획안 및 도메인 파악
- 상세 기능 구현 목록 작성
- 개발 기능 구현별로 가능한 최대하의 인수테스트 목록 작성
- 개발완료는 인수테스트 완료로 보고
즉 할 일을 정하고 그 일을 했는지는 인수테스트로만 인정하는 셈입니다. 이유는 간단합니다. 저희는 개발사라 반드시 납품이 되어야하고 납품이 된다는 뜻은 단위테스트가 통과하는게 아니라 고객 입장에서 작동시킬 때 문제없어야 한다는 의미이기 때문입니다. 이렇다보니 이러한 기조를 뒷받침하는 보다 발전되고 상세한 생각을 정리하고 이해하기 쉬운 룰로 만들고 싶은 니즈가 항상 있습니다.
특히 테스트작성이나 측정 뿐 아니라 개발방법론에 보다 밀접하게 융화시켜 부드러운 개발공정을 유도하고 싶은 거죠.
인수테스트 작성의 어려움
제가 직원들과 함께 인수테스트목록을 작성하면서 느낀 큰 문제점이 있습니다. 개발물에 대한 사용경험과 개발경험이 적절한 인수테스트항목을 정하는데 지대한 영향을 끼친다는 사실입니다. 즉 신입들은 인수테스트 작성을 시켜도 구멍이 슝슝 뚫린 – 작성한 목록을 통과해도 도저히 제품레벨이라 부를 수 없는 – 테스트항목을 작성합니다.
예를 들면 ‘비밀번호 확인부터 하고 아이디 중복검사를 해도 되는가’ 같은 테스트를 잘 작성하지 못합니다.
그럼 노련한 다년차 개발자에게 시키면 잘 작성하냐라고 물어보면 그들은 너무 개발에 최적화되어 사용자측면은 간과하고 개발편의적으로 테스트를 작성합니다.
이도 예를 들면 ‘화면에 모든 내용이 잘 표시되는가’로 작성해버립니다. 실제 구동시켜보면 스크롤이 버벅거리거나 일부 내용이 너무 늦게 뜨고 하는데 말이죠.
이러한 상황에서 흔히 나올 대안은 ‘전문테스터에게 맡기면 된다’ 같은 외주발상입니다. 저는 그럴 생각은 전혀 없으니 내제화하기 위한 노력을 여러가지로 기울여봅니다.
책의 내용
이 책은 ATDD(인수테스트 주도개발)에 근거를 두고 책 전체의 내용을 전개합니다. 저자인 케네스퍼그는 졸트상도 수상한 적이 있는 개발자로 이 책에서도 발군의 집필능력을 보여주고 있습니다.
주의하실 점은 책에서 다루는 주 분야는 책 제목과 달리 개발론이 아닙니다 ^^;
주된 내용은 바로 위에서 언급했던 저의 고민을 효과적으로 해결해주는 것입니다. 인수테스트를 기반으로 개발해야 한다는 건 당연한 이 책의 기조입니다. 그 기조에 대한 근거를 설명하는 게 이 책의 내용이 아니라 실제 그래서 어떻게 효과적으로 인수테스트를 작성하는가에 대한 방법론이 바로 중요한 주제입니다.
제 블로그에 꽤나 자주 등장하는 테스트 주도 개발로 배우는 객체 지향 설계와 실천이란 책도 개발을 인수테스트 기반으로 해야한다라는 기조는 동일합니다만 실제 인수테스트 기반의 개발을 전개하는 개발방법론에 집중합니다. 인수테스트 목록은 자연스럽게 책에서 제시하고 있죠.
하지만 이 책은 다루는 분야가 ‘인수테스트 목록을 어떻게 작성하는가’에 맞춰져 있습니다.
사실 좋은 인수테스트 목록을 작성할 수 없으면 인수테스트 기반의 개발은 진행될 수 없으니까 이 책이 ATDD에서는 더 기초서라고 할 수 있습니다(…랄까 더 기반을 다져주는 내용을 책으로 내주셔서 감사합니다)
균형잡힌 인수테스트란 그것을 통과하면 충분히 납품될 수 있는 품질을 확보하고 고객이 만족할 수 있는 개발물이 산출되는 것이라 할 수 있겠죠.
그러한 인수테스트 목록을 만들기 위해 이 책이 제시하는 것은 테스터, 고객, 개발자라는 3명의 입장을 고루 반영해야 한다는 것입니다. 말로야 뭔들…
근데 그러한 삼위일체를 이루기 위한 구체적인 시나리오와 각 상황별 커뮤니케이션 방법을 보여주는게 이 책의 대부분 내용입니다.
게다가 시나리오들이 제법 현실 상황과 비슷해서 꽤나 참고가 됩니다. 나라면 저 상황에서 어떻게 했을까하고 개발사 오너로서 입장을 이입해볼 수 있는 포인트가 여러 개 나옵니다(아마 저자 본인도 개발프로젝트를 이끄는 팀장으로서의 경험을 책에 녹여냈기 때문이 아닐까요 ^^)
ATDD가 와닿는 분들에게는 즐겁게 읽을 수 있는 책이라 생각합니다.
recent comment