인수테스트 주도 개발 과정을 소개합니다.

1. 인수테스트 주도 개발
( Acceptance Test
Driven Development )
오재훈 (주)넷스루 연구소장
( jaehoon@nethru.co.kr,
ojh420@gmail.com,
https://www.facebook.com/jaehoon.oh.503 )

2. 테스팅 재정의하기
http://www.skylinetechnologies.com/Insights/Skyline-Blog/July-2013/Test-Planning-Part-1-Improving-Your-Test-Results
시스템이 요구사항 대로 동작하는지를 테스트하는
것은 테스팅인가?

3. 테스팅 재정의하기
새로운 정의:
- 체킹 : 요구사항 대로 구현되었는지 검사하는 과정
- 테스팅 : 시스템이 요구사항 대로 동작한다고 가정했을 때,
기계적으로 검증할 수 없는 시스템의 동작 방식을
탐색하고 발견하고 배우는 과정

4. Checking
- 이미 가지고 있는 믿음이 있을 때, 그 믿음과 일치하는지 검사하는 과정
- 우리가 알고 있는 시스템의 동작방식을 확인하는 것
- 프로그램이 합의된 사양대로 동작하는지를 확인하는 데 초점을 둔다.
- 결과는 흑백중 하나다.
- 기계적인 검증이 가능하다.
Testing
- 시스템에 대해서 아직 모르는 것을 찾기 위한 활동
- 탐색, 발견, 배움의 과정이다.
- 시스템이 어떻게 동작하는지에 대해 충분히 배우는데 초점을 둔다.
- 결과는 예측할 수 없다.
- 시스템의 행동을 관찰하고, 가치 판단이 개입되기 때문에 기계적 검증이
불가능하다.
테스팅 재정의하기

5. 테스터
프로그래머
요구사
항
명세서
명세
읽기
설계
구현
테스트
명세
읽기
테스
트
설계
테스트
수행
버그
수정
테스트
수행
버그
수정
테스트
수행
...
프로그래머와 테스터는 어떻게 협력하는가?
전통적인 개발 프로세스

6. 전통적인 개발 프로세스
http://www.skylinetechnologies.com/Insights/Skyline-Blog/July-2013/Test-Planning-Part-1-Improving-Your-Test-Results

7. 전통적인 개발 프로세스
1. 현재 개발중인 기능이 어느 정도 진척되었나요? ( 개발 진척도 판단 기준 )
2. 현재 개발중인 기능이 언제쯤 완성이 될까요? ( 개발 완료 판단 기준 )
3. 기능을 검증할 테스트 케이스를 언제 설계 하나요?
4. 개발자들이 테스트케이스를 알고 있나요?
5. 테스트 언제 실행 하나요?
6. 테스트를 누가 수행 하나요?
7. 발견된 버그에 대한 정보들을 어떻게 주고 받나요?
8. 코드 구현 - 테스트 수행 - 버그 전달에 걸리는 시간은 얼마나 되나요?
9. 버그수정후 테스트를 재수행했을 때 회귀결함이 얼마나 많이 발생하나요?
10. 프로그래머와 테스트는 어떻게 협력하나요?
11. 어떤 비용들이 발생하고 있나요?
12. ...
이 질문들에 답해보세요.

8. 전통적인 개발 프로세스
요구사항 명세서

9. Communication Bandwidth

10. Communication Bandwidth

11. 인수테스트 주도 개발

12. 프로그래머
인수테스트 주도 개발 (ATDD)
사용자
스토리
스토리
1 구현
요구사항
이해하기
예제 도출하기
예제 정제하기
인수
테스
트
작성
테스터
인수
테스
트
작성
스토리
1
탐색적
테스팅
스토리
2 구현
스토리
2
탐색적
테스팅
프로
그래머
테스터
고객

13. 사용자 스토리(User Story)

14. 인수 조건(Acceptance Criteria)

15. 인천공항 주차장 요금표
http://www.airport.kr/pa/ko/d/3/2/4/index.jsp
※ 단기주차장의경우 주말(금·토·일),법정 공휴일, 동·하계 성수기(7월1일~8월31일, 12월1일~익년1월31일) 기간에는 상기 성수기
요금을 적용
구 분
최초 방문 시 2회차
방문시
3회차 방문부터
(변경요금)비성수기 성수기
단기주차장 소형
(시간당 2,400원)
기본 30분 1,200원
추가 15분 600원
(시간당 2,800원)
기본 30분 1,400원
추가 15분 700원
(시간당 2,400원)
기본 30분 1,200원
추가 15분 600원
일 12,000원 일 14,000원 일 18,000원 일 24,000원
장기주차장
(주차타워
포함)
소형
(시간당 1,000원)
일 9,000원
대형
(30분당 1,200원)
일 12,000원
화물터미널
주차장
소형
최초 45분 무료
추가 15분 500원
일 10,000원
대형
최초 45분 무료
추가 15분 600원
일 12,000원

16. 이 상태에서 프로그래머가 구현을 시작한다면 어떤
일이 생길까요?
요구사항을 다르게 이해할 수 있는 가능성이
있을까요?
인수테스트 주도 개발 (ATDD)

17. 요구사항을 다르게 이해할 가능성들
고객이 2016년 3월 16일 0시 0분 0초에 주차장에 들어와서, 30분 59초에 주차장을
나갔다. 몇 분으로 계산해야 하는가? ( 초를 어떻게 처리해야 하는가? )
전날 23시 50분에 주차장에 들어와서, 다음날 0시 20분에 주차장을 나가면
주차요금은 얼마인가? (하루의 기준)
고객이 2016년 3월 17일(목) 23시에 주차장에 들어와서 성수기 요금을 받는 18일
(금요일) 오전 01 시에 주차장을 나갔다면 요금은 얼마인가? ( 성수기/비수기
혼합시 계산방법 )
고객이 2016년 3월 17일(목) 23시 59분에 주차장에 들어와서 성수기 요금을 받는
18일(금요일) 오전 00 시 1분에 주차장을 나갔다면 요금은 얼마인가? (
성수기/비수기 혼합시 계산방법 )
...

18. ATDD 개발 과정
예제로
명세하기
예제 정제하기
실행 가능한
명세 만들기
Growing Object Oriented Software Guided by Tests by Steve Freeman & Nat Pryce

19. 예제로 명세하기
고객(혹은 대리인), 프로그래머, 테스터가
협력해서 명세를 작성한다.
추상적인 요구사항을 동일하게 이해하기
위해서 객관적이고 구체적인 예제를
이용한다.
프로
그래
머
테스
터
고객

20. 명세 정제하기
예제가 과도하게 많이 작성된 경우
관련성이 적은 정보를 제거하고
개발과 테스트에 필요한 정보만을 남긴다.

21. 명세 정제하기
도메인 용어가 있다면 도메인 용어를
이용하여 예제를 기술한다.

22. 테스트 자동화 프레임워크
Fit
Concordian
RobotFramework
Cucumber
JBehave
FitNesse
Selenium
Easyb
Watir
Arbiter

23. Cucumber 를 이용한 Specification 작성
Feature: 기능을 간략히 서술
기능에 대한 상세 설명
Scenario: 시나리오의 제목
Given 시나리오를 테스트하기 전의 시스템 상태를 기술(사전조건)
When 시스템에 발생시켜야 하는 이벤트를 기술
Then 이벤트가 발생했을 때 시스템이 사후상태를 기술(사후조건)

24. 실행 가능한 Specification 만들기
Scenario Outline: [비수기] 단기 주차장에 주차한 경우 주차 요금을 계산한다.
When 방문객이 비수기에 단기 주차장에 <duration>동안 주차한다.
Then 방문객은 주차요금으로 <cost>원을 지불해야 한다.
Examples:
| duration | cost |
| 1분 | 1200 |
| 30분 | 1200 |
| 31분 | 1800 |
| 45분 | 1800 |
| 1시간 | 2400 |
| 5시간 | 12000 |
| 5시간 1분 | 12000 |
| 1일 | 12000 |
| 1일 1분 | 13200 |
| 1일 31분 | 13800 |
| 2일 1분 | 25200 |
| 3일 1분 | 37200 |

25. Cucumber 명세 예제
Feature: 인천공항 주차장의 주차 요금을 계산한다.
여기에 사용자 스토리를 적어주세요...
Scenario Outline: [비수기] 단기 주차장에 주차한 경우 주차 요금을 계산한다.
When 나는 평일에 단기 주차장에 <duration>동안 주차한다.
Then 나는 주차요금으로 <cost>원을 지불해야 한다.
Examples:
| duration | cost |
| 1분 | 1200 |
| 30분 | 1200 |
| 31분 | 1800 |
| 45분 | 1800 |
| 1시간 | 2400 |
| 5시간 | 12000 |
| 5시간 1분 | 12000 |
| 1일 | 12000 |
| 1일 1분 | 13200 |
| 1일 31분 | 13800 |
| 2일 1분 | 25200 |
| 3일 1분 | 37200 |

26. Cucumber Test 코드 작성
package com.inchon.parking;
import org.junit.runner.RunWith;
import cucumber.api.CucumberOptions;
import cucumber.api.junit.Cucumber;
@RunWith(Cucumber.class)
public class ShortTermParkingLotTest {
}

27. Cucumber Step Definitions
public class ShortTermParkingLotStepDefinitions {
@When("^방문객이 평일에 단기 주차장에 (.+)동안 주차한다.$")
public void 방문객이_평일에_단기_주차장에_분동안_주차한다(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}
@Then("^방문객은 주차요금으로 (d+)원을 지불해야 한다.$")
public void 방문객은_주차요금으로_원을_지불해야_한다(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}
@When("^방문객이 주말에 단기 주차장에 (.+)동안 주차한다.$")
public void 방문객이_주말에_단기_주차장에_분동안_주차한다(int arg1) throws Throwable {
// Write code here that turns the phrase above into concrete actions
throw new PendingException();
}
...
}

28. Cucumber 테스트 자동화 아키텍처
Examples
Test Framework
Glue Code
Support Code
Application
Under Test
*.feature
Cucumber
Cucumber Test
Step Definitions
Support Code
Production
Code

29. Cucumber
Test
실행 화면

30. Cucumber
Test
실행 화면

31. 테스트 시나리오 품질
도출된 테스트 시나리오는
1. 비지니스 규칙을 기술하고 있는가?
2. 테스트 시나리오의 의도가 잘 드러나는가?
3. 쉽게 이해할 수 있는가?
4. 유지보수 비용이 많이 들지 않는가?

32. 테스트 시나리오 기술 수준
https://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/

33. 테스트 시나리오 기술 수준
시니라오 기술
수준
설명
Technical Activity
● 시스템을 구현한 기술을 기준으로 테스트 시나리오를 작성하는 방법
● 테스트 시나리오에 기술과 관련된 용어들이 나타난다.
● 구현과 관련된 기술이 바뀌거나 시스템을 사용하는 순서가 바뀌면 테스트
시나리오를 수정해야 한다.
작업 흐름
( Workflow )
● 사용자가 시스템을 사용하는 작업의 흐름을 기준으로 테스트 시나리오를
작성하는 방법
● 테스트 시나리오에서 기술과 관련된 용어들이 나타나지 않기 떄문에
기술이 바뀌어도 테스트 시나리오는 바뀌지 않는다.
● 작업 흐름이 바뀌는 경우에는 테스트 시나리오를 변경해야 한다.
비지니스 규칙
( Business Rule )
● 비즈니스 규칙이 명확히 드러나도록 테스트 시나리오를 작성하는 방법
● 구현과 관련된 기술이 바뀌어도 테스트 시나리오를 수정하지 않아도 된다.
● 작업 흐름이 바뀌어도 테스트 시나리오를 수정하지 않아도 된다.

34. Technical Activity 로 기술하기
1. 인천공항 주차 요금 계산기 페이지로 접속한다.
2. 도착 예정 날짜 입력창에 “2015-10-14” 로 입력한다.
3. 도착 예정 시각 입력창에 “10”시로 입력한다.
4. 도착 예정 분 입력창에 “0” 분으로 입력한다.
5. 출차 예정 날짜 입력창에 “2015-10-14” 로 입력한다.
6. 출차 예정 시각 입력창에 “10” 시로 입력한다.
7. 출차 예정 분 입력창에 “30” 분으로 입력한다.
8. 차종 선택 라디오버튼에서 차종을 “소형" 으로 선택한다.
9. 주차장 선택 라디오버튼에서 주차장을 “단기"로 선택한다.
10. “요금계산하기" 버튼을 클릭한다.
11. 주차 요금 계산 결과 텍스트를 읽어서 값이 1200원인지 확인한다.

35. 작업흐름(Workflow) 로 기술하기
1. 인천 공항 주차 요금 계산 페이지에 접속한다.
2. 도착 예정 시각을 “2015-10-14 10:00” 으로 설정한다.
3. 출차 예정 시각을 “2015-10-14 10:30” 으로 설정한다.
4. 차종을 소형으로 선택한다.
5. 요금을 계산을 요청한다.
6. 계산 결과가 “1200” 원이어야 한다.

36. 비지니스 규칙으로 기술하기
Scenario: 평일 단기 주차장의 소형차 주차 요금을 계산한다.
When 고객이 평일에 소형차를 단기 주차장에 1분간 주차한다.
Then 고객은 주차요금으로 1200원을 지불해야 한다.

37. ATDD 도입으로 인한 변화
항목 Waterfall ATDD
의사소통과 협력 요구사항을 다르게 해석할 수 있음
개발자-테스터간 소통량이 적음
개발 막바지에 협력
고객-프로그래머-테스터간의 공통의
이해
프로그래머-테스터간의 소통량이
많아짐
개발 과정에서 수시로 협력해야 함
테스트 설계 시점 구현 진행이 완료되기 전 요구사항 명세 공유시
테스트 설계 방법 QA 팀에서 독자적으로 작업 고객, QA, 프로그래머 공동 작업
테스트 시나리오 작성
시점
개발이 완료될 무렵 개발전
인수테스트 실행 시점 프로그래머가 구현 종료후 테스터가
실행
프로그래머가 구현시 수시로 실행
진척도 판단 기준 프로그래머의 직관(감?) 인수테스트 통과 비율
완료 판단 기준 프로그래머의 직관(감?) 인수테스트 통과 비율 100%
역할의 변화 프로그래머 :
- 구현만 담당
테스터 :
프로그래머 :
- 구현
- 체킹 : 스펙대로 구현되어

38. ATDD 도입으로 얻을 수 있는 것들
● 요구사항은 추상적이어서 경험과 생각의 차이로 다르게
해석할 수 있지만, 예제는 구체적이고 객관적이기
때문에 다르게 해석하기 어렵다.
● 구체적인 예제를 이용해서 고객-프로그래머-테스터가
요구사항을 동일하게 이해하게 된다.
● 프로그래머가 요구사항을 오해해서 발생하는 버그를
미연에 방지할 수 있다.
● 프로그래머-테스터간에 발생할 수 있는 갈등을 방지할
수 있다.

39. 감사합니다.