단위 테스트의 정의는 비교적 명확한데 비해 인수 테스트는 용어의 혼란이 있어 보입니다. 그래서 저는 위키피디아를 참고하여 인수테스트의 정의를 살펴보았습니다. 위키피디아에도 문맥에 따른 여러 가지 정의가 있지만 XP(eXtream Programming)에서 사용하는 정의가 제가 이 글에서 사용하려는 의미에 가장 근접 하다고 생각합니다.

“Acceptance testing is a term used in agile software development methodologies, particularly Extreme Programming, referring to the functional testing of a user story by the software development team during the implementation phase.”

“인수 테스트는 애자일 개발 방법론, 그러니깐 특별히 XP에서 구현단계에서 개발팀이 사용자 스토리 기반의 기능 테스트를 하는 것을 나타내기 위한 용어이다.”

그림#1. Selenium 2.0을 이용한 인수 테스트

앞서 얘기했듯이 단위 테스트는 정말 탁월한 검증방법 중 하나이지만 단위라는 문맥을 벗어나지 못하는 것이 단점입니다. 다시 말해 테스트의 초점이 각 단위에 맞춰져 있기 때문에 시스템의 여러 요소들이 상호작용하는 것을 테스트하는 데 있어서는 적합하지 않습니다. 리팩토링 프로젝트를 할 때 저는 단위 테스트에 무척 매료되었던 적이 있습니다. 단위 테스트를 잘 작성하면 어떠한 리팩토링이든 잘 검증할 수 있을 것 같았습니다. 저는 특정 부분을 리팩토링을 하며 지나칠 정도로 꼼꼼하게 단위 테스트를 작성했습니다. 하지만 결국 QA 단계에서 오류가 발견되었습니다. UI 영역에서 발생한 오류였습니다. 자세히 살펴보니 제가 작성한 단위 테스트가 UI 영역 까지 검증하지 못했기 때문에 발생한 일이었습니다. 사실 이런 부분은 인수 테스트로 검증하는 것이 좋습니다. 인수 테스트는 보통 기능 단위로 테스트하고 하나의 기능은 굉장히 많은 단위가 결합되어 있습니다. 그래서 단위 테스트만으로는 찾아내기 힘든 부분인 여러 요소들이 상호작용하며 생길 수 있는 문제점을 발견할 수 있게 도와줍니다.

인수 테스트는 사람이 수행할 수도 있고 실제로 QA인력이 수행하기도 합니다. 하지만 검증비용을 생각한다면 Selenium, Fitness와 같은 도구들을 이용하여 자동화하는 것이 좋습니다. 제가 일하는 환경에서는 인수 테스트를 QA인력이 수행했었으나 최근 위 도구를 이용하여 자동화를 시도하고 있습니다. 

단위 테스트와 마찬가지로 인수 테스트를 CI 서버합하면 빠른 피드백을 받아 검증시점을 앞당길 수 있습니다. 하지만 단위 테스트와 달리 인수 테스트는 보통 실행하는 데 시간이 오래 걸리기 때문에 커밋빌드에 포함시키기 보다는 일일빌드에 포함시키는 경우가 많습니다. 하지만 이 경우 피드백 주기가 느려지는 단점이 생깁니다. 이에 대한 보완책으로써 매우 핵심적인 인수 테스트만 구분하여 커밋빌드에서 실행하는 방법이 있습니다.