테스트는 버그를 확인하기 위한 것이지 실행을 확인하기 위한 것이 아니다

아래의 글에서 두 가지 좋은 실천사항을 이끌어 낼 수 있었다.

 

첫째는 버그 발견 시의 주의사항이다. 일상적으로 버그를 발견하는 사람이 담당자에게 우쭐해 하며 지적하는 광경을 보게 되는데, 이점은 조직의 단합에 도움이 안된다는 것이다. 이것을 해소하기 위해 프로젝트 오리엔테이션 시간등을 활용해 PM이 모든 구성원에게 주의를 환기시킬 필요가 있다고 생각한다.

 

둘째는 테스트 시나리오의 목적에 대한 수정사항이다. 프로젝트에서 만드는 테스트 시나리오는 대체적으로 요건에 맞는 실행이 되는지는를 확인하기 위해 한다. 사실상 버그를 발견하기 위한 테스트는 되지 못하는 것이다. 그래서 릴리즈 이후에 나오는 버그들로 몸살을 앓는 경우가 많다. 그런 의미에서 우리의 테스트는 관점을 바꿀 필요가 있다. "실행을 단순히 확인하는 것"이 아니, 버그를 확인하기 위한 것으로 말이다.

 

다른 많은 팀과 달리 스토리 주도의 애자일 프로젝트를 진행하는 팀은 테스트 실행과 대립하지도 적대적이지도 않다. 다른 사람이 개발한 내용을 테스트하다가 버그를 발견하더라도 우쭐해 하지 않는다. 설령 그 버그가 전체 개발을 지연시키더라도 비난하지 않는다. 협력을 강조하는 '모두 함께 한다'는 마음가짐이 이를 가능하게 한다.

 

애자일 프로젝트에서는 버그를 찾아 제거하기 위해 테스트를 한다. 100% 코드 실행 확인(code coverage)이나 모든 경계 조건 검사를 목표로 할 필요는 없다. 우리의 직관과 지식, 그 동안의 경험을 이용하여 테스트에 들이는 노력을 조절할 수 있다.

 

준비가 되었다면 누구라도 테스트를 수행할 수 있다. 고객은 개발자와 전담 테스터의 도움을 받아 인수 테스트를 명시할 책임이 있다. 예를 들어 표6.1의 테스트에서 유효기간 만료에 관한 테스트는 마스터카드 하나에 대해서만 명시되어 있다. 만약 모든 경우에 대해 처리하기를 원한다면 다른 카드에 대해서도 테스트를 명시해야 할 것이다. 하지만 고객은 개발자와의 대화를 통해, 카드 종류에 상관없이 유효기간 검사는 동일하게 진행되기 때문에, 한 종류만 테스트해도 충분하다는 것을 알게 된다. 시간이 지나면서 의사소통을 자주 하고 실패하는 테스트의 유형을 살펴봄으로써, 프로젝트 구성원들은 테스트에서 들이는 노력을 효과적으로 집중하는 방법을 배우게 된다.

<사용자 스토리> p.116