ATDD는 무엇인가?

누구나 겪을 수 있는 상황

개발을 하다 보면 요구사항이 명확하지 않거나 부족한 경우에 많은 고민을 해본 적이 있을 것이다.

기획자에게 물어보거나 같이 요구사항을 해석하면서 개발하면 고객이 원하는 결과물이 아닐 경우가 높다.

기획자와 같이 요구사항을 재확인하여 수정해야 한다.

이런 상황을 예방하고 올바른 요구사항을 충족하려면 고객에게 질문해야 한다.

전화를 하거나 이메일 보내도 고객이 실시간으로 확인하는 것 아니기 때문에 응답에 시간이 걸린다.

답변을 받아도 이해하기 힘들 경우에 다시 정리해서 요청하기도 한다.

개발은 점점 딜레이 되고 고객의 불만이 조금씩 쌓인다.

문제의 원인은 서로 생각하는 관점이 다르기 때문이다.

괴리감을 해결하기 위해선 커뮤니케이션이 필요한데 전화 & 이메일은 한계가 뚜렷하다.

결과물이 나오고 나서야 서로 생각이 다르다는 걸 깨닫기엔 늦는다.

가장 좋은 방법은 처음부터 다양한 관점을 하나로 모으는 것이다.

*설명은 린 애자일 기법을 활용한 테스트 주도 개발의 대여점 예제와 NEXTSTEP의 ATDD와 함께 클린 API로 가는 길 기반으로 진행한다.

(현재 과정명이 ATDD, 클린 코드 with Spring 으로 변경되었다.)

ATDD (Acceptance Test Driven Develpoment)

ATDD는 다양한 관점을 가진 고객, 개발자, 테스터 등과 협업하기 위한 애자일 방법 중 하나이며,

다양한 관점으로 인한 리스크를 방지하고자 기획 단계부터 인수 테스트를 통해 공통의 이해를 도모하고

함께 인수 테스트를 작성하기 때문에 구체적이며 불필요한 반복을 줄여준다.

ATDD에 필요한 3인 체제

고객, 개발자, 테스터가 기획부터 서로가 소통하고 협업하면서 서로 업무 도메인과 개발, 테스트를 학습하게 된다.

- 고객 : 요구사항을 결정하고 인수 테스트를 생성하고 우선순위를 결정한다.

- 개발 : 요구사항을 구현하고 인수 테스트를 통과하는지 확인한다.

- 테스터 : 구현이 어떻게 동작하는지 잘못 동작하는지 검사한다.

이러한 3인 체제로 작성된 인수 테스트는 시스템 테스트와 차이가 없어서 고품질의 소프트웨어를 생성할 수 있게 된다.

3인 체제는 최소한의 고객, 개발, 테스트 역할이 필요하다는 의미로 사용한다.
혼자서 개발, 테스트 역할을 할 수 있다면 고객을 포함해서 2인으로 진행하거나
반대로 새로운 역할을 추가하여 3인 이상 모여도 무방하다.

ATDD 프로세스

ATDD 프로세스는 4가지 활동(논의, 증류, 개발, 데모)과 4가지 산출물(사용자 스토리, 인수 조건, 인수 테스트, 소프트웨어) 그리고 업무 가치로 구성되어 있다.

순서대로 알아보자.

1. UserStory

사용자 스토리(UserStory)는 고객이 원하는 기능(요구사항)을 간단하게 표현한다.

고객이 원하는 대여점 기능은 다음과 같다. (린 애자일 기법을 활용한 테스트 주도 개발의 대여점 예제)

- CD의 대여와 반납
- 현금 대신 쓸 수 있는 신용카드를 사용 가능하게 하기
(생략)

사용자 스토리의 표현 형식은 익스트림 프로그래밍의 기준을 따르며 다음과 같다.

<역할>을 가진 사람으로, 나는 <행동>을 하고자 하고, <이유>를 하기 위함이다.

- <역할>은 사용자를 대변한다.

- <행동>은 사용자가 이루고자 하는 일이다.

- <이유>는 왜 사용자가 그 행동을 하는가다.

사용자 스토리를 시작하기 전에 스토리에 들어가는 역할을 생각해보는 게 좋다.

역할
점원 : CD를 대여해주고 반납받는다.
창고 관리자 : 전체 CD 재고를 추적한다.
재무 관리자 : 대여 요금과 연체비와 같은 모든 거래를 관리한다.
대여자 : CD 대여에 대해 요금(현금, 신용카드)을 지급한다.

정리된 역할로 페르소나를 작성하는데, 이러한 페르소나는 사용자 스토리 작성에 도움이 된다.

페르소나(Persona)

페르소나란 상세한 설명으로 표현되는 상상의 인물로 역할 설명에 사용된다.

페르소나를 작성하기 위해선 역할의 속성이 필요하는데, 이러한 속성은 시스템 설계와 사용성 테스트에 좋은 아이디어를 제공한다.

시스템을 사용하는 점원에 대해서 속성을 정리해보자.

점원 속성
- 사용 빈도 : 누군가 얼마나 자주 시스템을 이용하는가
- 분야 전문기술(domain expertis) : 어떤 분야에 대해 시스템이 설계되었는가
- 컴퓨터 전문기술(computer expertis) : 컴퓨터 사용에 대한 숙련도
- 일반 목표 : 편리성이나 프로세스 개선 같이 시스템에 대한 목표

고객의 말을 들어보면 점원 역할은 정식 점원과 임시 점원 2가지로 구분된다고 한다.

페르소나는 추측이 아닌 데이터를 기반으로 작성해야 한다.

각 점원에 맞게 속성을 작성하면 다음과 같다.

역할 속성
정식 점원
- 사용 빈도 : 매일
- 분야 전문기술 : 대여 업무에 대해 아주 능숙함
- 컴퓨터 전문기술 : 아주 능숙하게 컴퓨터를 다룸.
- 일반 목표 : 빠른 대여 속도(키 입력을 최대한 줄이는 방향)

임시 점원
- 사용 빈도 : 일주일에 한 번
- 분야 전문기술 : 기본적인 대여 업무만 숙지
- 컴퓨터 전문기술 : 컴퓨터 사용에 미숙함
- 일반 목표 : 대여에 도움을 주는 여러 가지 알림 기능

속성이 작성되었으면, 가상의 임시 점원 페르소나를 작성해보자.

가상의 인물은 임의의 이름으로 작성한다.

임시 점원 페르소나
'래리'는 클래식 음악을 좋아하는 퇴임한 영어 교수다. 일주일에 한 번 CD의 대여와 반납을 돕기 위해 온다.
실수 없이 자신의 일을 처리하는 것을 자랑스럽게 생각한다.
최신 기술에 대해 잘 모르는 편으로 그래픽 사용자 인터페이스가 익숙하지 않아 아이콘 자체가 그에겐 별 의미가 없어 보인다.
시스템이 복잡해지면 잘 사용할 수 있을지 궁금해한다.

페르소나가 작성되었다면 사용자 스토리를 작성할 차례이다.

페르소나는 어떤 사용자 인터페이스를 만들어야 할지 도움을 주고 상기시켜준다

역할 점원과 대여자로 스토리를 작성해보자.

사용자 스토리
점원(역할)으로서, 나는 고객에게 CD를 대여(행동)해주고, 누가 빌려갔는지 기록하기 위함(이유)이다.
대여자(역할)로서, 나는 대여점에서 CD를 빌린다.(행동)
(생략)

작성된 사용자 스토리는 <역할>, <행동>이 가장 중요(필수적인 요소)하다.

<이유>는 도움이 되지만 필수적인 요소는 아니다. (상세한 사항은 스토리 개발 직전이나 개발 중에 기술한다.)

사용성 테스트나 탐험적 테스트를 진행할 때,
해당 역할의 관점으로 시스템 기능을 살펴봐야 한다.

사용자 스토리가 작성이 되었으면 다음 단계로 넘어간다.

2. Discuss & Acceptance Criteria

사용자 스토리가 작성되면, 이를 가지고 의논(Discuss)하면서 스토리에 대한 인수 조건(Acceptance Criteria)을 만든다.

인수 조건이란 최종 사용자 혹은 시스템이 제시하는 요구사항을 만족하는지 판별하기 위한 기준이다.

Acceptance는 수락, 받아들임의 뜻을 가지지만, 인수로 해석한 이유는 인수를 수락한다는 의미로 해석

이전 단계에서 작성된 사용자 스토리다.

점원으로서, 고객을 위해 CD를 대여한다.
점원으로서, 고객을 위해 CD를 반납받는다.
창고관리자로서, 모든 CD에 대해 어떤 CD가 대여되었는지, 창고에 있는지 알고 있다.
재무관리자로서, 얼마나 많은 CD가 반납일을 지키지 않는지, 연체금은 얼마인지 알고 있다.
재무관리자로서, 대여되는 CD에 대해 신용카드로 결제를 받아서 현금을 관리하지 않고 싶다.
재무관리자로서, 신용카드 결제가 얼마나 되었는지 알고 싶고, 은행 계좌 잔고가 얼마인지 알고 싶다.

사용자 스토리를 통해 인수 조건을 만들어보자.

인수 조건은 사용자의 관점에서 기능을 정의한다.

스토리 인수 조건
CD 대여
- CD를 대여한다. 대여로 기록되었는지 확인한다.

CD 반납
- CD를 반납받는다. 반납으로 기록되었는지 확인한다.
- CD를 연체 반납으로 받는다. 연체되었다고 기록되어 있는지 확인한다.

창고 보고서
- 여러 개의 CD를 대여한다. 보고서에 해당 CD를 대여한 것으로 표시하는지 확인한다.
- 여러 개의 CD를 반납받는다. 보고서에 반납받은 모든 CD들이 창고에 있는 것으로 나타내는지 확인한다.

*대여 요금
- CD를 반납받는다. 대여 요금이 맞는지 확인한다. 신용 카드 결제 요금이 대여 요금과 일치하는지 확인한다. 신용카드 회사 요금을 결제한다. 결제한 금액이 은행 계좌에 입금되었는지 확인한다.

마지막 대여 요금이 보면 다른 인수 조건에 비해 많은 내용을 담고 있는데 작은 스토리로 분리가 되는지 확인해야 한다.

대여 요금 계산
- CD를 반납받는다. 대여 요금이 맞는지 확인한다. 신용 카드 결제 요금이 대여 요금과 일치하는지 확인한다.

요금 정산
- 신용카드 회사로 요금을 결제한다. 결제한 금액이 은행 계좌에 입금되었는지 확인한다.

대여 요금이 대여 요금 계산, 요금 정산으로 분리되었다.

인수 조건을 보면 스토리마다 다양한 요금 이 사용되고 있는데, 구성원이 용어마다 의미를 다르게 볼 수 있기 때문에 모두가 동의하는 용어집을 만든다. (고객 언어 기준으로 작성)

대여 요금 : 대여할 당시의 요금
연체료 : 반납 시 연체일 때 발생하는 요금
카드 요금 : 어떤 이유에서든 고객의 신용카드로 결제가 이루어질 요금

스토리 인수 조건을 용어집에 맞게 수정한다.

대여 요금 계산
- CD를 반납받는다. 대여 요금이 맞는지 확인한다. 카드 요금이 대여 요금과 일치하는지 확인한다.

요금 정산
- 카드 요금이 카드 회사에 의해 결제되었는지 확인한다. 은행 계좌로 카드 요금이 입금되었는지 확인한다.

작은 스토리일수록 개발과 테스트가 쉬워진다.
스토리를 상세화 할 때 인수 테스트가 커진다면 작은 스토리로 나눠보자.

모든 스토리는 업무 가치(Business Value)와 노력 2가지로 평가할 수 있다.

- 업무 가치는 다른 업무와 비교할 때, 스토리가 상대적으로 가치가 있는지 알려주며, 이를 측정하는 요소는 이익 증가, 지출 감소, 적은 자원 사용, 고객 만족, 리스크 회피 등 다양하게 발견할 수 있다.

각 스토리에 가치를 주기 위해 피보나치 수열(1,2,3,5,8,13, ...)이나 제곱승(1,2,4,8,16, ...)을 사용할 수 있으며, 같은 행은 동일한 가치를 가진다.

- 노력은 코드 구현, 테스트, 기타 다른 모든 일을 포함해서 스토리 개발에 드는 모든 노력을 의미한다.

반복 주기에 들어가는 노력이 상대적으로 비슷하다면, 업무 가치 곡선의 기울기는 대략적으로 투자 대비 효과가 된다.

유스케이스(시나리오) 작성하기

유스케이스는 사용자 스토리 기반으로 작성하는데 다음과 같은 유형이 있다.

- 보통 시스템 외부에서 발생하는 일련의 행동

- 다른 유스케이스 작업 흐름의 일부

이전에 보았던 사용자 스토리 중 하나인 CD 대여를 다시 보자.

점원으로서, 고객에게 CD를 빌려주고, 누가 CD를 빌려갔는지를 기록하고 싶다.

간단히 표현된 상태지만 이를 업무 흐름에 따라 서술하면 다음과 같이 자세한 내용이 나온다.

고객이 선반에서 CD 케이스를 선택한다(케이스에는 커버 페이지만 있다.)
고객이 점원에게 CD 케이스를 가져온다.
고객이 카운터 뒤에 있는 선반의 다른 케이스에서 실제 CD를 꺼낸다.
고객이 본인의 신분을 확인할 수 있는 운전면허증을 보여준다.
점원이 CD 케이스에서 대여 카드를 꺼낸다.
점원이 고객 이름을 적고 대여 날짜를 적는다.
고객이 대여 카드에 사인을 한다.
점원이 대여 카드를 카운터 위에 있는 박스 안에 넣고 뒤에 있는 선반에 커버 페이지가 있는 CD 케이스를 놓는다.

해당 업무 흐름에서 시스템이 대신하는 단계만 추려보면 다음과 같다.

1. 점원이 고객의 ID와 CD ID를 시스템에 입력한다.
2. 시스템이 정보를 기록한다.
3. 시스템이 고객의 사인이 되어 있는 문서를 프린트한다.

추려진 단계는 유스케이스의 주 시나리오(경로)가 되며 시스템이 동작해야 할 순서가 되기도 한다.

유스케이스를 작성하는 템플릿은 다음과 같은 형태를 가진다.

간단한 유스케이스 템플릿
이름 : 쉽게 참조할 수 있어야함. (스토리 이름)
설명 : 간단한 노트 (스토리에 대한 설명)
액터(Actor) : 유스케이스를 시작하는 사람(사용자)
선처리 조건(Pre-condition) : 유스케이스가 시작되기 전에 반드시 수행되야 할 일 (주 경로 실행전 필요한 시스템의 상태)
후처리 조건(Post-condition) : 유스케이스가 성공적으로 수행되고 반드시 수행되어야 할 일 (주 경로 이후 변경된 시스템의 상태)
주 경로(Main course) : 일련의 상호작용을 보여주는 과정

대여에 관한 스토리와 추려진 업무 흐름 단계를 템플릿에 기입하면 다음과 같다.

대여 유스케이스
이름 : CD를 대여한다
설명 : 고객에게 CD를 대여한다
액터(Actor) : 점원
선처리 조건(Pre-condition) : 고객은 ID를 가지고 있어야 한다. CD에도 ID가 있어야한다.
후처리 조건(Post-condition) : CD는 대여 중으로 기록된다. 대여증이 프린트돼야 한다.
주 경로(Main course)
1. 점원이 고객의 ID와 CD ID를 시스템에 입력한다.
2. 시스템이 정보를 기록한다.
3. 시스템이 고객의 사인이 되어 있는 문서를 프린트한다.

선처리부터 후처리까지 잘못될 일 없이 성공하는 유스케이스를 작성했는데,

성공하는 주 시나리오를 정상 경로(happy path)라고 한다.

하지만 진행 중에 후처리 조건에 도달하지 못하는 상황이 발생할 수 있는데

이를 예외라고 하며, 모든 유스케이스에서 예외가 발생할 수 있다.

예외가 발생하면 해당하는 주 시나리오 단계와 발생한 순서대로 번호를 붙이거나 문자를 붙여서 표시한다.

예외 상황 - 고객 ID 인증 불가
1a. 고객의 ID가 첫번째 시도로 인증이 되지 않는다.
단계1을 반복한다.
1b. 고객의 ID가 두번째 시도에도 인증되지 않았다.
점원은 수작업으로 고객 ID를 기록하여 CD를 대여해준다.
유스케이스를 종료한다.

시스템 오류로 고객 ID 인식이 안되거나, 등록이 안된 ID 일지도 모르는 예외 시나리오다.

정책 때문에 예외가 발생하는 것도 있다.

예외 상황 - 대여 제한 개수 초과
1c. 고객이 업무 규칙에 제한되어 있는 CD 수 이상을 대여하려고 한다.
점원이 고객에게 더 이상 대여할 수 없음을 알려준다.
유스케이스를 종료한다.

업무 규칙
- CD 대여 제한 개수
- 고객은 한 번에 최대 3개의 CD만 대여 가능하다.

이러한 예외는 테스트를 만들어야 할 시나리오가 된다. 또한 성공, 예외 말고도 대안 유스케이스도 존재한다.

대안
3a. 프린터에 용지가 걸렸다.
점원이 직접 용지를 교체한다.
유스케이스를 종료한다.

이렇게 작성된 유스케이스는 여러 효과가 있다.

- 작업 흐름 중에서 컴퓨터가 담당하는 것을 문서화한다고 볼 수가 있다. (메뉴얼로 사용이 가능)

- 유스케이스 시나리오로 인수 테스트를 제안한다.

유스케이스는 시스템의 기능적인 요구사항을 잡아내는 기술이다.
시나리오는 사용자와 시스템 간의 교류를 단계적으로 나타낸 것이다.

3. Distill & Acceptance Test

도출된 인수 기준으로 인수 테스트(Acceptance Test)를 작성한다.

사용자의 관점으로 인수테스트가 작성되기 때문에 사용자의 의도대로 작동하는지 확인하는 방법이 되기도 한다.

기본적인 테스트 구조는 다음과 같다.

Given <설정>
When <이벤트나 동작>
Then <예상되는 결과>

유스케이스와 비슷한 형태다.

Given은 선처리 조건(Pre-condition)

When은 주 경로(Main course)

Then은 후처리 조건(Post-condition)로 보면 된다.

바로 이전단계에서 작성한 대여 유스케이스다.

대여 유스케이스
이름 : CD를 대여한다
설명 : 고객에게 CD를 대여한다
액터(Actor) : 점원
선처리 조건(Pre-condition) : 고객은 ID를 가지고 있어야한다. CD에도 ID가 있어야한다.
후처리 조건(Post-condition) : CD는 대여 중으로 기록된다. 대여증이 프린트돼야 한다.
주 경로(Main course)
1. 점원이 고객의 ID와 CD ID를 시스템에 입력한다.
2. 시스템이 정보를 기록한다.
3. 시스템이 고객의 사인이 되어 있는 문서를 프린트한다.

해당 유스케이스로 테스트 구조를 작성하면 아래와 같다.

Given(설정)
고객이 ID를 가진다 (초기 시스템 상태)
CD가 ID를 가진다 (초기 시스템 상태)
CD는 현재 대여 상태가 아니다 (초기 시스템 상태)
When(트리거)
점원이 고객 ID와 CD ID로 대여해준다 (시스템 동작)
Then(트리거)
CD는 대여 중이라고 기록된다 (최종 시스템 상태)
대여증이 출력된다 (인쇄)

이렇게 작성된 인수 테스트는 블랙박스 테스트가 된다.

좀 더 명세화해서 문장에 상세 데이터를 넣는 형태로 작성하면 다음과 같다.

Given(설정)
고객이 ID:007, 이름:제임스를 가진다
CD는 ID:CD2, 제목:Beatles Greatest Hits, 기본상태:비대여를 가진다
대여정책의 대여 기간은 2일이다.
현재 날짜는 2011년 1월 21일이다.
When(트리거)
점원이 고객 ID와 CD ID로 대여해준다
Then(트리거)
CD는 상태가 대여 중이라고 기록된다.
고객정보(ID:007, 이름:제임스)와 CD정보(ID:CD2, 제목:Beatles Greatest Hits, 기본상태:비대여) 그리고 반납예정일 2011년 1월 23일이 적힌 대여증이 인쇄된다.

인수 테스트 구조는 팀에 맞는 형태로 사용하면 된다.

이제 실패하는 인수 테스트를 작성해보자.

이미 대여한 CD를 대여요청해서 예외가 발생하는 케이스다.

Given(설정)
고객이 ID:007, 이름:제임스를 가진다
CD는 ID:CD2, 제목:Beatles Greatest Hits, 기본상태:대여를 가진다
When(트리거)
점원이 고객 ID:007와 CD ID:CD2로 대여할 때 에러가 발생한다.
-> 에러 메시지 : CD_Already_Rented

인수 테스트가 작성이 되었다면 다음 단계로 넘어간다.

참고사항 - 스토리 충돌 문제
고객이 대여를 할 때 예외가 동시에 발생한다.
- 미반납 CD가 존재한다
- 최대 개수를 초과해서 대여하려고 한다.
이렇게 스토리 충돌 문제 때문에 어떤 에러 메시지를 보여줘야할지 고민한 적이 있을 거다.
이 경우엔 고객과 협의하여 예외 우선순위를 정하면 된다.

블랙박스 테스트(Black Box Test)