왜 개발과 테스트가 분리되면 안되는가?
테스트 기간의 단축을 위한 노력..
예전에 L모 전자회사의 DTV사업부에서 의뢰받은 컨설팅에 참여한 적이 있다.
엄밀히 말하면 DTV사업부의 Q팀(거기에서는 품질팀을 Q팀으로 부르고 있었다)이 의뢰를 한 것인데 주 의뢰 내용은
「테스팅 프로세스의 효율화를 통해 많은 테스트 업무 량을 줄이기」
였다.
인터뷰 등으로 상황을 파악해 보니 DTV의 신모델은 우후죽순으로 개발팀에서 쏟아져 나오는데 이의 검수를 맡고 있는 부분은 Q팀이 1군데 였다. 그러다보니 너무 Q팀의 부하가 많이 걸리기 일쑤이고 이는 곧 테스트 기간의 연장 등으로 그 부작용이 나타나는 것이었다.
우리「컨설팅 팀」이 내 놓은 해법은 결국 'Early Testing' 해법이었고 이를 위해 각 제품의 설계 단계에서부터 Q팀의 멤버들이 들어가서 활동을 해야 한다는 보고서를 내 놓았다.
생각해 보면 그 컨설팅 결과는 실패하였다. 채택이 되지 못했기 때문이다. 지금 돌이켜 보면 위 방법을 적용하기에는 다음과 같은 문제가 있었다.
개발팀 vs 품질팀(Q팀)의 인력 비율이 多:1
품질팀 멤버의 개발 초기단계에서 참가하기에는 부족한 맨파워.
특히 첫번째 항목은 우리가 내린 결론을 적용하기에 너무나 치명적인 허들이었다. 품질인력이 그 수많은 개발 회의들을 각각 참여하기에는 너무 인력이 부족한 것이다. 두번 째 항목은 해당 조직 자체의 문제로서 교육을 통해 해결을 할 수 있을 것이었다. (물론 이는 나의 생각이다.)
이 문제를 'Early Testing(초기 테스트)' 으로 해결을 하는 게 방향이라면, 품질팀이 단독으로 할 일은 매우 제한적이어서 불가능에 가깝다. 개발 사이클 내에서 초기 테스트가 이뤄져야 하는데 조직의 구조상 품질팀 하나가 이를 전부 커버하기 힘들다면 개발 사이클 내에서 '개발팀' 이 이를 수행하여야 한다. 개발자가 이런 테스트에 대하여 부담을 느낀다면, 개발팀 내 테스트 전담 인력이 있어 그 인력들이 테스트를 개발 사이클 내에서 수행을 하여야 한다.
이렇게 한다면 기존 '품질팀' 의 역할은 없어져야 한다고 생각할 것이다. 지금 드는 생각은 품질팀의 역할은 '최종 체크리스트' 의 수행이다. 개발팀에서 넘어온 테스트 결과물을 검토하여 부족한 것이 있는지 검토하고, 검토 후 최종 체크리스트 수행 후 릴리즈를 한다면 개선이 되지 않을 까? 결국은 개발과 테스트는 분리될 것이 아니고 하나로 합쳐저 운영이 되어야 하며 최종 검수는 그 나름대로의 별도의 역할을 정의해야 한다.
당시 위와 같은 사항들을 생각하지 못한 것은 나의 능력이 뛰어나지 못했기 때문이리라. 위 솔루션은 어디까지나 가설(仮説)이라 '이렇게 하세요' 라고 말을 하지는 못하겠다.
하지만 스타트업 및 IT기업 들을 중심으로 하는 케이스를 보면 위와 같은 내용 비슷하게 운영하는 개발 팀장들이 의외로 많다. 개발팀에서 개발을 하고 테스트 코드 작성은 별도의 외주 인력으로 하는 케이스도 보았고 (물론 릴리즈 전에 체크리스트를 통한 체크는 이뤄진다) 개발팀이 자체적으로 테스트 + 자동화 하는 케이스도 수도 없이 봐왔다. 단지 위 사례는 DTV라는 하드웨어 중심이라 조금 적용하는데 어려웠던 것이리라.
결국 테스트 프로세스 개선을 하려면 뭔가 조직적으로 변화가 이뤄져야 하며, 이는 개발+테스트 의 방향으로 가는 게 맞는 것 같다.
