인수테스트 주도 개발

인수테스트 주도 개발( Acceptance Test

Driven Development )오재훈 (주)넷스루 연구소장

( [email protected], [email protected],

https://www.facebook.com/jaehoon.oh.503 )

mailto:[email protected]



https://www.facebook.com/jaehoon.oh.503

https://www.facebook.com/jaehoon.oh.503

테스팅 재정의하기

http://www.skylinetechnologies.com/Insights/Skyline-Blog/July-2013/Test-Planning-Part-1-Improving-Your-Test-Results

시스템이 요구사항 대로 동작하는지를 테스트하는 것은 테스팅인가?


새로운 정의:- 체킹 : 요구사항 대로 구현되었는지 검사하는 과정

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

Checking- 이미 가지고 있는 믿음이 있을 때, 그 믿음과 일치하는지 검사하는 과정- 우리가 알고 있는 시스템의 동작방식을 확인하는 것- 프로그램이 합의된 사양대로 동작하는지를 확인하는 데 초점을 둔다.- 결과는 흑백중 하나다. - 기계적인 검증이 가능하다.

Testing- 시스템에 대해서 아직 모르는 것을 찾기 위한 활동- 탐색, 발견, 배움의 과정이다. - 시스템이 어떻게 동작하는지에 대해 충분히 배우는데 초점을 둔다.- 결과는 예측할 수 없다. - 시스템의 행동을 관찰하고, 가치 판단이 개입되기 때문에 기계적 검증이 불가능하다.


테스터

프로그래머

요구사항

명세서

명세읽기

설계구현

테스트

명세읽기

테스트설계

테스트수행

버그수정

테스트수행

버그수정

테스트수행

...

프로그래머와 테스터는 어떻게 협력하는가?

전통적인 개발 프로세스


http://www.skylinetechnologies.com/Insights/Skyline-Blog/July-2013/Test-Planning-Part-1-Improving-Your-Test-Results


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

10. 프로그래머와 테스트는 어떻게 협력하나요?11. 어떤 비용들이 발생하고 있나요?12. ...

이 질문들에 답해보세요.


요구사항 명세서

Communication Bandwidth

Communication Bandwidth

인수테스트 주도 개발

프로그래머

인수테스트 주도 개발 (ATDD)

사용자 스토리

스토리1 구현

요구사항 이해하기

예제 도출하기

예제 정제하기

인수 테스트 작성

테스터

인수 테스트 작성

스토리1

탐색적테스팅

스토리2 구현

스토리2

탐색적테스팅

프로그래머

테스터

고객

사용자 스토리(User Story)

인수 조건(Acceptance Criteria)

인천공항 주차장 요금표

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원

이 상태에서 프로그래머가 구현을 시작한다면 어떤 일이 생길까요?

요구사항을 다르게 이해할 수 있는 가능성이 있을까요?

인수테스트 주도 개발 (ATDD)

요구사항을 다르게 이해할 가능성들

고객이 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분에 주차장을 나갔다면 요금은 얼마인가? ( 성수기/비수기 혼합시 계산방법 )

...

ATDD 개발 과정

예제로 명세하기

예제 정제하기

실행 가능한 명세 만들기

Growing Object Oriented Software Guided by Tests by Steve Freeman & Nat Pryce

예제로 명세하기

고객(혹은 대리인), 프로그래머, 테스터가 협력해서 명세를 작성한다.

추상적인 요구사항을 동일하게 이해하기 위해서 객관적이고 구체적인 예제를 이용한다.

프로그래머

테스터

고객

명세 정제하기

예제가 과도하게 많이 작성된 경우

관련성이 적은 정보를 제거하고

개발과 테스트에 필요한 정보만을 남긴다.

명세 정제하기

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

테스트 자동화 프레임워크

Fit

Concordian

RobotFramework

Cucumber

JBehave

FitNesseSelenium

Easyb

Watir

Arbiter

Cucumber 를 이용한 Specification 작성

Feature: 기능을 간략히 서술

기능에 대한 상세 설명

Scenario: 시나리오의 제목

Given 시나리오를 테스트하기 전의 시스템 상태를 기술(사전조건)

When 시스템에 발생시켜야 하는 이벤트를 기술

Then 이벤트가 발생했을 때 시스템이 사후상태를 기술(사후조건)

실행 가능한 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 |

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 |

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 {

}

Cucumber Step Definitionspublic class ShortTermParkingLotStepDefinitions {

@When("^방문객이 평일에 단기 주차장에 (\\.+)동안 주차한다\\.$")public void 방문객이_평일에_단기_주차장에_분동안_주차한다(int arg1) throws Throwable {

// Write code here that turns the phrase above into concrete actionsthrow new PendingException();

}

@Then("^방문객은 주차요금으로 (\\d+)원을 지불해야 한다\\.$")public void 방문객은_주차요금으로_원을_지불해야_한다(int arg1) throws Throwable {


}

@When("^방문객이 주말에 단기 주차장에 (\\.+)동안 주차한다\\.$")public void 방문객이_주말에_단기_주차장에_분동안_주차한다(int arg1) throws Throwable {


}

...

}

Cucumber 테스트 자동화 아키텍처Examples

Test Framework

Glue Code

Support Code

ApplicationUnder Test

*.feature

Cucumber

Cucumber TestStep Definitions

Support Code

ProductionCode

Cucumber Test

실행 화면

Cucumber Test

실행 화면

테스트 시나리오 품질

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

테스트 시나리오 기술 수준

https://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/

테스트 시나리오 기술 수준시니라오 기술 수준

설명

Technical Activity

● 시스템을 구현한 기술을 기준으로 테스트 시나리오를 작성하는 방법● 테스트 시나리오에 기술과 관련된 용어들이 나타난다.● 구현과 관련된 기술이 바뀌거나 시스템을 사용하는 순서가 바뀌면 테스트 시나리오를 수정해야 한다.

작업 흐름( Workflow )

● 사용자가 시스템을 사용하는 작업의 흐름을 기준으로 테스트 시나리오를 작성하는 방법

● 테스트 시나리오에서 기술과 관련된 용어들이 나타나지 않기 떄문에 기술이 바뀌어도 테스트 시나리오는 바뀌지 않는다.

● 작업 흐름이 바뀌는 경우에는 테스트 시나리오를 변경해야 한다.

비지니스 규칙 ( Business Rule )

● 비즈니스 규칙이 명확히 드러나도록 테스트 시나리오를 작성하는 방법● 구현과 관련된 기술이 바뀌어도 테스트 시나리오를 수정하지 않아도 된다.● 작업 흐름이 바뀌어도 테스트 시나리오를 수정하지 않아도 된다.

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

10. “요금계산하기" 버튼을 클릭한다.11. 주차 요금 계산 결과 텍스트를 읽어서 값이 1200원인지 확인한다.

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

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

ATDD 도입으로 인한 변화항목 Waterfall ATDD

의사소통과 협력 요구사항을 다르게 해석할 수 있음개발자-테스터간 소통량이 적음개발 막바지에 협력

고객-프로그래머-테스터간의 공통의 이해프로그래머-테스터간의 소통량이 많아짐개발 과정에서 수시로 협력해야 함

테스트 설계 시점 구현 진행이 완료되기 전 요구사항 명세 공유시

테스트 설계 방법 QA 팀에서 독자적으로 작업 고객, QA, 프로그래머 공동 작업

테스트 시나리오 작성 시점

개발이 완료될 무렵 개발전

인수테스트 실행 시점 프로그래머가 구현 종료후 테스터가 실행

프로그래머가 구현시 수시로 실행

진척도 판단 기준 프로그래머의 직관(감?) 인수테스트 통과 비율

완료 판단 기준 프로그래머의 직관(감?) 인수테스트 통과 비율 100%

역할의 변화 프로그래머 : - 구현만 담당테스터 :

- 체킹 : 스펙대로 구현되어 있는가?

- 탐색적 테스팅

프로그래머 :- 구현- 체킹 : 스펙대로 구현되어 있는가?

테스터 - 탐색적 테스팅

ATDD 도입으로 얻을 수 있는 것들

● 요구사항은 추상적이어서 경험과 생각의 차이로 다르게 해석할 수 있지만, 예제는 구체적이고 객관적이기 때문에 다르게 해석하기 어렵다.

● 구체적인 예제를 이용해서 고객-프로그래머-테스터가 요구사항을 동일하게 이해하게 된다.

● 프로그래머가 요구사항을 오해해서 발생하는 버그를 미연에 방지할 수 있다.

● 프로그래머-테스터간에 발생할 수 있는 갈등을 방지할 수 있다.

감사합니다.