열린 공간, 누가바닷컴

나는 1년짜리 프로젝트를 하고 있다. 1년이라는 기간 안에 3번의 마일스톤(Milestone)이 존재하고, Stabilization 도 세 번 있다. 한 번의 마일스톤은 약 3개월의 기간으로 잡혀있지만, 실제 개발을 하고 테스트를 하는 기간은 마일스톤 당 약 1~1/5개월, 4~6주이다. 그 동안 프레임워크를 만들고 기능을 만들어 추가하며 테스트를 진행해야 한다.

4주에서 6주, 그러니까 3번의 마일스톤 기간이 있으니 12주에서 18주의 개발 기간 동안 테스트할 계획을 세우고 테스트를 하는 것이 내 일이다. 물론 그 중간에 있는 Stabilization 기간에도 테스트를 하지만, 이는 그 동안 발생한 오류, 버그, 개선책을 적용하고 테스트하는 기간이므로 계획되고 잘 짜인 테스트 활동과는 조금 차이가 있다. 나는 그 기간에 여러 테스트 계획과 수행을 하고 있지만, 생각해보면 기능 테스트에 가장 많은 시간을 부여하고 있는 것이 아닌가 한다. 기능을 검증하기 위해 설계를 하고, 실제 테스트를 진행하고, 버그를 리포트하고, 이 모든 것들을 Regression testing의 효율성을 위해 자동화 테스트 코드를 개발하는데 많은 시간과 노력을 투자한다. 물론 성능, 스트레스, 보안 등등 다양한 테스트를 빠짐 없이 수행하고 있지만, 절대적인 노력의 양으로 본다면 기능에 많이 집중된 것이 아닐까 생각된다.

되짚어보면, 대부분의 시간과 노력을 내가 맡은 부분에 대한 테스트에 소요하고 있다는 것을 알 수 있다. 당연히 그렇겠지만 말이다. 그런데, 프로젝트를 수행하다 보면, 뭔가 애매한 부분이 발생하는 경험을 한 적이 있을지도 모른다. 누군가 해야 하는데, 정확하게 누가 해야 하는지 모르는 부분이 있을 때도 있고, 내가 만든 테스트 케이스/시나리오가 아닌데, 내가 맡은 부분에서도 해봐야 하는 것들이 있을 때도 있고, 또는 다른 사람이 담당하는 영역인데, 내 기능을 위해 어쩔 수 없이 내 테스트에 포함해서 테스트해야 하는 부분이 있을 수 있다. 우리 회사에서는 이 모든 것들을 Test Tax 라고 부른다. 세금(Tax)처럼 테스터들이 반드시 책임져야 하는 부분들을 통칭하는 말이다.

서로의 전문 영역이 존재하는 규모가 큰 집단일 경우, 성능이나 보안, UX 와 같이 전문 지식과 경험을 필요로 하는 영역의 테스트는 전문가가 따로 있는 경우가 많다. 그러나 그 전문가들이 모든 부분에 대하여 테스트를 진행할 수도 있고, 그렇지 않을 수도 있다. 그들이 만든 가이드라인이나 테스트 케이스/시나리오를 각자의 영역에 적용하여 테스트를 하는 경우가 그 대표적인 예가 될 수 있을 것이다.

물론 보안, 성능 등과 같은 부분은 기능을 담당하는 테스터가 반드시 검증해야 하는 부분이다. 그러므로 Tax가 아니라고 주장할 수도 있다. 그런데 왜 굳이 이들을 Tax라고 부르고 있는 걸까? 그것에는 또 다른 이유가 있다. 대부분의 프로젝트에서 기능을 제외한 테스트 항목들은 기능 테스트만큼 자주, 많이 테스트하지 않는다. 개발 초기에 리서치도 하고 사용자 패턴을 분석하여 만든 디자인으로 사용성 테스트를 수행하고 중간쯤에 한 번 더, 그리고 마지막에 수행한다면 꽤 많은 횟수의 테스트를 하는 것일 테다. 그리고 보안이나 스트레스, 성능 역시, 개발이 꽤 진척이 된 상황에서 몇 번의 수행으로 평가를 하고, 개선하려고 한다. 마치 1년에 몇 번 납부하는 세금과 비슷하지 않은가? 그래서 우리는 이렇게 부르는 것이다.

내가 경험한 Test Tax 중에 이런 것이 있었다. 프로젝트 중반에서 후반으로 넘어갈 때, 큰 변화가 있었다. 바로 아랍어 지원이 추가된 것이다. 이를 위해 Globalization팀이 개발 및 테스트 계획을 세워서 진행한다고 했지만, 이 기능이 추가됨으로 해서, 내가 담당하고 있는 기능과 한국 시장에 공급될 제품에 어떤 영향이 있을 수 있는지 검토와 검증이 필요했다. 현실적으로 모든 기능을 Globalization팀이 테스트해볼 수 없고, 자동화 테스트에 아랍어를 추가하는 부분도 그들이 Code owner가 아니기 때문에, 그리고 수십만 개의 테스트 시나리오와 수백만 라인의 테스트 코드를 그들이 일일이 수정할 수는 없는 일이기 때문이다. 나는 새로 추가되는 기능의 Scope을 확인하고, 몇 가지 조합의 수를 내 케이스에 추가하였다. 그리고 기능이 추가된 버전이 릴리즈되었을 때 테스트를 하였고, 부족한 부분을 더 채워 넣는 일을 진행하였다. 이러한 일들이 Test Tax이다. 그다지 내키지 않는 일인 경우도 있으나, 내가 경험하지 못한 부분이어서 무척 재미있는 경우도 있다.

Posted by 갼이