ISTQB 용어집은 인수 테스트 주도 개발(ATDD, Acceptance Test-Driven Development)을 이해관계자의 도메인 언어로 인수 테스트를 정의하는, 협업에 바탕을 둔 테스트 우선 접근법으로 정의한다.[1] ISTQB CTFL 강의계획서에 따르면 ATDD는 시스템 설계 과정의 일부로 인수 기준에서 테스트를 끌어내고, 애플리케이션의 해당 부분을 개발하기 전에 그 테스트를 먼저 쓴다.[2]
테스트로 개발을 이끄는 접근
이 강의계획서는 TDD, ATDD, 행위 주도 개발(BDD, Behavior-Driven Development)을 테스트로 개발을 이끄는 비슷한 개발 접근으로 묶는다. 셋 모두 코드를 쓰기 전에 테스트를 정하므로 일찍 테스트하는 원칙을 실천하고 shift left를 따르며, 반복적 개발 모델을 뒷받침한다. 세 접근 모두 테스트를 자동 테스트로 남겨, 나중에 코드를 고치거나 리팩터링할 때 코드 품질을 지키는 데 쓸 수 있다.[2]
협업 기반 테스트 접근
블랙박스, 화이트박스, 경험 기반 테스트 기법은 저마다 결함을 찾는 데 목적을 두지만, 협업 기반 접근은 협업과 소통으로 결함을 피하는 데에도 초점을 둔다. 이 강의계획서는 협업 기반 접근으로 사용자 스토리를 함께 쓰는 일, 인수 기준, ATDD를 다룬다.[2]
사용자 스토리
사용자 스토리(user story)는 시스템이나 소프트웨어의 사용자나 구매자에게 가치가 있을 기능을 나타낸다. 사용자 스토리에는 3C(Card, Conversation, Confirmation)라 부르는 세 가지 핵심 측면이 있다.[2]
- Card: 사용자 스토리를 적는 매체. 예: 인덱스 카드, 전자 보드의 항목
- Conversation: 소프트웨어를 어떻게 쓸지에 대한 설명. 문서로 남기거나 말로 한다.
- Confirmation: 인수 기준[2]
가장 흔한 꼴은 “[역할]로서 나는 [이루려는 목표]를 원한다. 그래서 [그 역할이 얻는 비즈니스 가치]를 할 수 있다”이고, 그 뒤에 인수 기준이 붙는다. 사용자 스토리를 함께 쓸 때는 브레인스토밍과 마인드맵 같은 기법을 쓸 수 있고, 비즈니스, 개발, 테스트 세 관점을 함께 담아 무엇을 내놓을지에 대한 공통의 그림을 얻는다. 좋은 사용자 스토리는 INVEST(Independent, Negotiable, Valuable, Estimable, Small, Testable)를 갖춰야 한다. 이해관계자가 사용자 스토리를 어떻게 테스트할지 모른다면, 스토리가 충분히 명확하지 않거나, 그 이해관계자에게 가치 있는 것을 담지 않았거나, 이해관계자가 테스트에 도움을 받아야 하는 것일 수 있다.[2]
인수 기준
이 강의계획서는 사용자 스토리의 인수 기준(acceptance criteria)을, 이해관계자가 그 스토리의 구현을 받아들이려면 구현이 갖춰야 할 조건으로 정의한다. 이 관점에서 인수 기준은 테스트가 실행해야 할 테스트 조건으로 볼 수 있다. 인수 기준은 대개 Conversation의 결과로 나온다.[2]
인수 기준은 다음에 쓴다.[2]
- 사용자 스토리의 범위 정하기
- 이해관계자 사이의 합의
- 긍정 시나리오와 부정 시나리오 기술
- 사용자 스토리 인수 테스트의 바탕
- 정확한 계획과 추정[2]
인수 기준을 쓰는 가장 흔한 꼴은 둘이다. 시나리오 지향 꼴은 BDD에서 쓰는 Given/When/Then 꼴이 그 예이고, 규칙 지향 꼴은 확인 항목의 목록이나 입력과 출력의 대응을 표로 적은 것이 그 예다. 인수 기준 대부분은 이 둘 가운데 하나로 적을 수 있지만, 잘 정의되고 모호하지 않다면 팀이 다른 꼴을 써도 된다.[2]
ATDD의 진행
ATDD에서는 사용자 스토리를 구현하기 전에 테스트 케이스를 만든다. 테스트 케이스는 고객, 개발자, 테스터처럼 관점이 다른 팀원이 만들고, 수동으로 실행하거나 자동화할 수 있다.[2]
- 명세 워크숍: 팀원이 사용자 스토리와, 아직 없으면 그 인수 기준을 분석하고 논의해 글로 쓴다. 사용자 스토리의 불완전함, 모호함, 결함을 이 과정에서 푼다.
- 테스트 케이스 만들기: 팀 전체나 테스터 혼자 만든다. 테스트 케이스는 인수 기준에 바탕을 두고, 소프트웨어가 어떻게 동작하는지 보이는 예로 볼 수 있어서 팀이 사용자 스토리를 올바르게 구현하도록 돕는다.[2]
예와 테스트가 같은 것이어서 두 말을 흔히 바꿔 쓴다. 테스트를 설계할 때는 블랙박스, 화이트박스, 경험 기반 테스트 기법을 쓸 수 있다. 처음 테스트 케이스는 대개 예외나 오류 조건 없이 모든 것이 예상대로 갈 때의 올바른 동작을 확인하는 긍정 테스트다. 긍정 테스트 케이스를 마치면 부정 테스트를 하고, 마지막으로 성능 효율성, 사용성 같은 비기능 품질 특성을 다룬다.[2]
테스트 케이스는 이해관계자가 이해할 수 있게 쓰고, 대개 필요한 사전 조건, 입력, 사후 조건을 담은 자연어 문장으로 적는다. 테스트 케이스는 사용자 스토리의 특성을 모두 커버하되 스토리를 넘어서면 안 되고, 두 테스트 케이스가 같은 특성을 기술해서도 안 된다. 테스트 자동화 프레임워크가 받는 꼴로 적으면, 개발자는 사용자 스토리의 기능을 구현하면서 받침 코드를 써서 테스트 케이스를 자동화할 수 있다. 그러면 인수 테스트는 실행할 수 있는 요구사항이 된다.[2]
행위 주도 개발
ISTQB 용어집은 행위 주도 개발(BDD)을 팀이 고객을 위해 컴포넌트나 시스템의 기대 동작을 내놓는 데 집중하고, 그 동작이 테스트의 바탕이 되는 협업 개발 접근법으로 정의한다.[3] CTFL 강의계획서에 따르면 BDD는 애플리케이션에 바라는 동작을 이해관계자가 이해하기 쉬운 단순한 자연어 꼴의 테스트 케이스로 나타내고, 대개 Given/When/Then 꼴을 쓴다. 이 테스트 케이스는 그 뒤 실행할 수 있는 테스트로 자동으로 옮겨져야 한다.[2]