추가 적립 안내

이 책은 개발자와 테스터가 소프트웨어 구현 전에 고객과 함께 인수 테스트(acceptance test)를 결정하고 각 개발 단계별로 이를 활용함으로써 어떻게 하면 소프트웨어가 목적한 바를 정확하게 구현할 수 있는지에 대해 샘(Sam)이라는 가상인물이 소프트웨어 프로젝트를 진행하는 과정을 보여줌으로써 매우 쉽게 설명한다.

★ 요약 ★

요구사항을 신속하고 명확하게 결정하지 못하거나, 고객의 바람을 반영하지 못해 프로젝트 후반부에서 곤란했던 경험이 있는가? 이 책은 개발자와 테스터가 소프트웨어 구현 전에 고객과 함께 인수 테스트(acceptance test)를 결정하고 각 개발 단계별로 이를 활용함으로써 어떻게 하면 소프트웨어가 목적한 바를 정확하게 구현할 수 있는지에 대해 샘(Sam)이라는 가상인물이 소프트웨어 프로젝트를 진행하는 과정을 보여줌으로써 매우 쉽게 설명한다.


★ 이 책에서 다루는 내용 ★

■ 완전히 테스트 가능한 요구사항으로 소프트웨어를 개발하는 방법
■ 단순하고 컴포넌트화 된 테스트 작성방법과 누락된 로직을 검사하는 방법
■ 소프트웨어 시스템의 사용자 인터페이스, 서비스 구현과 그 외 까다로운 요소들을 테스트하는 방법
■ 외부 소프트웨어를 가장 잘 다룰 수 있도록 요구사항을 식별하는 방법
■ 테스트 결과를 표현하고 평가하여 프로젝트 진행상황을 측정하는데 사용하는 방법
■ 인수테스트를 만들어서 개발 조직과 고객에게 모두 이익을 줄 수 있는 방법
■ 대규모 프로젝트에 ATDD(인수 테스트 주도 개발, Acceptance Test-Driven Development)를 확대 적용하는 방법


★ 이 책의 구성 ★

1부: 고객, 개발자, 테스터의 3인 체제가 소프트웨어 시스템을 만드는 이야기를 다룬다. 1부에서는 인수 테스트가 어떻게 프로젝트 기획부터 각 사용자 스토리에 이르는 전체 프로세스에 녹아들 수 있는지를 보여준다.
2부: 인수 테스트를 분해하여 세세히 다룬다.
3부: 테스트 표현(test presentation)과 평가(evaluation)라는 일반적인 주제에 대해 다룬다. 4부: 실제 상황에 대한 사례 연구를 다룬다. 몇몇 상황은 관련이 있는 부분만을 보여주기 위해서 간략화 시켰다.
5부: 테스트 설정(Test Setup)을 어떻게 다루는지 등과 같은 좀 더 기술적인 주제에 관해 다룬다.
6부: 업무 가치와 테스트 자동화 같은 추가적인 주제를 부록에 실었다.

ATDD(인수 테스트 주도 개발, Acceptance Test-Driven Development)에 대한 요약과 이에 대한 장점을 빠르게 익히고자 하는 독자는 25장 ’회고와 관점’을 먼저 읽어보기 바란다. 다른 사람의 경험을 들어보고 싶은 독자는 에필로그를 읽어보기 바란다.


★ 추천의 글★

“이 책은 3명의 가상 프로젝트 이해관계자들이 프로젝트를 계획하고 진행하면서 사용한 애자일 기법에 대한 이야기로, 쉽게 이해하고 용이하게 적용할 수 있도록 구성되었다.”
조한스 브로드월(Johannes Brodwall) / 스테리아 노웨이(Steria Norway) 수석 과학자

“보통 애자일 개발은 짝을 이루어 행동하는 것이 전부라고 이야기한다. 나 역시 짝을 이루어 일을 하는 것이 매우 큰 효과를 낸다는 점에 동감한다. 하지만, 이 책을 읽은 후부터는 소프트웨어 개발을 주도하는 인수 테스트에 함께 참여하는 ’3인 체제(고객(혹은 업무 분석가) + 개발자 + 테스터)’의 팬이 되었다. 나 역시 고객과의 상호작용 패턴과 테스팅 패턴에 대해 글을 써 본 적이 있다. 읽기 쉽고 독자와 완벽하게 자신의 경험을 공유한, 케네스 퍼그의 이 책은 매우 훌륭하다. 스토리들과 실제 사례 연구와 그의 훌륭한 경험으로 가득차 있다. 충분히 일독할 가치가 있는 책이다.”
린다 라이징(Linda Rising) / 『Fearless Change: Patterns for Introducing New Ideas』의 공동 저자

“소프트웨어 개발에서 애자일 선언서, 익스트림 프로그래밍, 사용자 스토리, 테스트 주도 개발로 많은 것을 이룰 수 있지만 그것만으로는 충분치 않다. ‘명확한 요구사항, 정확한 구현, 완벽한 테스트 커버리지를 어떻게 보장할 것인가?’와 더욱 중요한 ‘고객의 만족과 수용을 어떻게 이끌어낼 것인가?’가 최근 대두되는 문제다. 우리가 놓치고 있는 부분은 고객에 의해 도메인 언어로 정의되고 고객의 언어로 작성된 인수 항목들이다. 그리고 린 애자일 인수 테스트 주도 개발이 바로 그 답이다.”
백스터 헬스케어(Baxter Healthcare) 수석 시스템 디자이너, 밥 보게티(Bob Bogetti)

“이 책은 필수 요구사항에 대한 사고, 사용자 인수 테스트, 린 애자일 사례를 통합하는 방법을 보여줌으로써 제품의 요구사항을 정확하고 효과적으로 도출할 수 있게 도와준다. 또한 요구사항 모델링과 밀접하게 관계가 있는 테이블 기반의 명세로부터 어떻게 인수 테스트의 기준을 도출하는지 설명한다. 인수 테스트에 부합하면서, 명확하고 모호하지 않은 요구사항을 정의하려는 린 애자일 팀 멤버들에게 꼭 필요한 필수 가이드북이다.
엘렌 고테스다이너(Ellen Gottesdiener) / 『Requirements by Collaboration』(Addison-Wesley Professional, 2001)과 『The Software Requirements Memory Jogger』의 저자, EBG 컨설팅, www.ebgconsulting.com,

“애자일 테스팅에 관한 단 한 권의 책을 읽어야 한다면, 바로 이 책을 읽길 권한다.”
데이비드 비드라(David Vydra) / http://testdriven.com,

“이 책은 실제 산업계에서 소프트웨어 개발을 주도하기 위해 테스트를 어떻게 사용해야 하는지에 대한 명확하고 직접적인 가이드를 제시한다. 이 책의 훌륭한 정보는 나를 흥분시켰다. 저자의 경험과 다른 전문가와 연구자료들의 참고자료가 매우 적절히 조화되어 있고, ATDD의 다양한 면을 보여주는 프로젝트 예제들이 잘 나타나 있다. 린 또는 애자일을 활용하지 않거나 단순히 최상의 소프트웨어 제품을 개발하고자 하는 프로젝트에서 일하지 않는다 해도 다양한 분야의 독자들이 이 책을 통해 활용할 수 있는 많은 것을 배울 것이다.
리사 크리스핀(Lisa Crispin) / 『애자일 테스팅』의 저자, ePlan 서비스의 애자일 테스터,


★ 저자의 말 ★
이 책의 주제는 테스트가 가능한 요구사항으로 소프트웨어를 개발하는 것이다. 테스트 가능한 요구사항은 인수 테스트(acceptance test)에 꼭 필요한 사항이다. 인수 테스트가 소프트웨어의 개발 방향을 정하기 때문이다. 많은 개발자가 이미 경험했듯이 요구사항을 구현하기 전에 인수 테스트를 먼저 생성해야, 오류를 줄이고 생산성을 높일 수 있다(책의 에필로그 부분의 예제 참조). 무엇이 구현되어야 하는지 명확하게 하기 위해 고객/업무 분석가, 개발자, 테스터는 인수 테스트를 함께 만들어낸다. ATDD에서 양질의 제품을 생산하기 위해서는 실제 테스트할 수 있을 만큼의 명확한 요구사항이 있어야 한다.
예를 들어 이 책이 여러분이 원하는 것을 만족시켜 준다는 걸 판단할 기준이 있는가? 이 책을 다 읽었을 때 어떻게 이 책이 당신의 기준들을 만족시켰는가? 이 책은 독자가 원하는 앞서 질문들에 대한 구현 방법을 보여준다. 여러분은 이미 이 책을 읽는 중이기 때문에 이 책의 인수 테스트 기준에 영향을 끼칠 기회가 없을 것이므로, 독자가 필요로 하는 기준이 무엇인지 다음과 같이 정리해봤다.
영어 수업에서 선생님은 육하원칙(누가, 무엇을, 언제, 어디서, 왜, 어떻게)을 강조한다. 그래서 이 책도 다음과 같이 육하원칙 아래에 그 기준을 만들어봤다.

■ 누가 인수 테스트를 생성하는가
■ 인수 테스트란 무엇인가
■ 언제 인수 테스트가 생성되어야 하는가
■ 어디에 인수 테스트가 사용돼야 하는가
■ 왜 인수 테스트 주도 개발이 효과적인가
■ 어떻게 인수 테스트를 생성하는가

이 책을 다 읽을 즈음에는 어떻게 테스트 가능한 요구사항이 소프트웨어 개발 프로세스를 좀 더 즐겁게 (혹은 좀 덜 고통스럽게) 만들고, 양질의 제품을 생산하는 데 도움을 주는지 이해할 것이다.

★ 옮긴이의 말 ★

“이건 사양이 정해졌어야 하는데…” 프로젝트 관리자나 개발자, 또는 품질보증 담당자로 테스트를 진행해본 경험이 있는 사람이라면, 소프트웨어 테스트를 진행하는 중에 사양이 정해져 있지 않아서 곤란했던 경험이 한 번씩은 있었을 것이다. 이러한 경험이 있다면 꼭 이 책을 읽어보기를 권한다.
개인적으로 애자일, 특히 테스팅에 관심이 많아서 이 책의 번역 제의가 들어왔을 때, 선뜻 번역을 하겠다고 이야기했다. 하지만, 번역을 진행하면서 이 책은 굳이 애자일에 관심이 없더라도, 소프트웨어 개발과 관련된 업무를 하고 있는 사람이라면 한 번쯤 읽어볼 만하다는 생각을 하게 되었다. 이 책은 요구사항을 결정해주는 고객과 이를 기반으로 소프트웨어를 구현하고 검증해야 하는 개발자와 테스터 간의 ‘긴밀하고 타이트한 협력’과 ‘빠른 피드백’을 강조하기 위해서 ‘린 애자일’ 이라는 단어를 붙인 듯 하다.
책의 내용은 가상 인물인 샘의 CD 대여점에서 사용할 시스템을 만들어가는 이야기인데, 소프트웨어 시스템을 구축하면서 어떻게 테스트 가능한 요구사항을 도출하는지와 어떤 방식으로 좀 더 명확하게 이를 이끌어내고 정리할 수 있는지를 아주 실질적이고 쉬운 예로 보여주고 있다. 실제로 번역을 진행하면서, “아~ 이런 부분은 이렇게 후배사원들에게 설명해주면 좋겠구나”라든가, “개발자들에게 명확한 요구사항의 중요성을 이런 식으로 설명할 수 있겠구나”라고 생각하고 한 부분들이 종종 있었다. 특히 요구사항을 표로 정리하고, 흔히 테스팅 분야에서 이야기하는 결정테이블(decision table) 형태로 표현하고 이를 분리하고 간략화해가는 내용 등은 실제 업무에서 큰 도움이 될 것이라고 생각한다.

1부 3인의 이야기
___1장 프롤로그
______1.1 소프트웨어 개발 방법
_________1.1.1 첫 번째 방법
_________1.1.2 두 번째 방법
_________1.1.3 차이점
______1.2 인수 테스트의 중요성
______1.3 시스템과 팀 소개
_________1.3.1 시스템
_________1.3.2 인물 소개
______1.4 정리

___2장 린과 애자일
______2.1 3인체제와 팀
______2.2 후 구현 테스트
______2.3 느린 피드백보다는 빠른 피드백
______2.4 구현 전의 테스트
______2.5 린과 애자일의 원리
______2.6 정리

___3장 테스트 전략
______3.1 테스트의 종류
______3.2 테스트가 수행되는 장소
______3.3 테스트 측면
_________3.3.1 제어점과 관찰점
_________3.3.2 새로운 테스트는 새로운 요구사항이다
______3.4 정리

___4장 인수 테스트 소개
______4.1 업무 규칙 예제
______4.2 인수 테스트의 구현
_________4.2.1 테스트 스크립트
_________4.2.2 사용자 인터페이스 테스트
_________4.2.3 xUnit 테스트
_________4.2.4 자동화 인수 테스트
_________4.2.5 종합 테스트
______4.3 테스트 절차
______4.4 정리

___5장 예제 프로젝트
______5.1 기획
_________5.1.1 목표
_________5.1.2 프로젝트 인수 테스트
______5.2 고수준의 요구사항
_________5.2.1 기능
_________5.2.2 기능 인수 기준
______5.3 정리

___6장 사용자 스토리 기술
______6.1 스토리
_________6.1.1 기능을 스토리로 분할
_________6.1.2 역할
_________6.1.3 역할 속성
_________6.1.4 페르소나
_________6.1.5 역할의 스토리
_________6.1.6 스토리 인수 기준
_________6.1.7 인수 테스트가 크기를 결정한다
_________6.1.8 고객 용어
______6.2 INVEST 기준
______6.3 정리

___7장 시나리오 협업
______7.1 사용자 스토리로부터 유스케이스 생성
_________7.1.1 간단한 유스케이스
_________7.1.2 예외와 대안.
_________7.1.3 인수 테스트
_________7.1.4 문서화
______7.2 스토리 지도
______7.3 개념적인 흐름
______7.4 의사소통
______7.5정리

___8장 테스트 분해
______8.1 3인체제의 테스트 생성
______8.2 테스트 컨텍스트
______8.3 테스트 구조
_________8.3.1 계산 테이블
_________8.3.2 데이터 테이블
_________8.3.3 액션 테이블
______8.4 예제 값으로 테스트
_________8.4.1 요구사항 수정
_________8.4.2 인수 테스트 수정
______8.5 문장에 있는 값으로 테스트
______8.6 테스트가 실행 시기와 장소
______8.7 정리

___9장 시나리오 테스트
______9.1 예외 시나리오 테스트
______9.2 업무 규칙 테스트
______9.3스토리 충돌 문제
______9.4 모든 것을 자동화할 수 없다
______9.5 다중 레벨 테스트
______9.6 사용자 인터페이스 테스트
______9.7 목표 검사
______9.8 정리

___10장 사용자 스토리 분할
______10.1 인수 테스트가 스토리 분할을 돕는다
______10.2 업무 규칙 테스트
______10.3 업무 규칙과 스토리
______10.4 정리

___11장 시스템 경계
______11.1 외부 인터페이스
_________11.1.1 상세사항
______11.2 외부 인터페이스 테스트
_________11.2.1 컴포넌트 테스트
_________11.2.2 테스트 더블과 모의 객체
______11.3 진짜와 가짜
______11.4 액티비티 스토리 지도
______11.5 정리

___12장 개발 리뷰
______12.1 나머지 스토리
_________12.1.1 사용성 테스트
_________12.1.2 화면과 상태의 분리
_________12.1.3 품질 속성 테스트
_________12.1.4 작업흐름 테스트
______12.2 개발 계획
______12.3 기획에서 인수까지
______12.4 정리

2부 상세사항

___13장 분리를 통한 간략화
______13.1 복잡한 업무 규칙
_________13.1.1 분리에 의한 간략화
_________13.1.2 단순화된 규칙
______13.2대여 이력
______13.3 정리

___14장 모델과 뷰의 분리
______14.1 사용자 인터페이스의 분리
______14.2 분리는 테스팅을 쉽게 한다
______14.3 정리

___15장 이벤트, 반응, 상태
______15.1 이벤트와 이벤트 테이블
______15.2 상태와 상태 전이
______15.3 내부 상태와 외부 반응
_________15.3.1 임시 상태나 영속 상태
_________15.3.2 젠 질문
______15.4 정리

___16장 개발자 인수 테스트
______16.1 컴포넌트 인수 테스트
_________16.1.1 필드 디스플레이 테스트
_________16.1.2 테이블 디스플레이 테스트
______16.2 정리

___17장 인터페이스 분리
______17.1 서비스 제공자에 대한 테스트
_________17.1.1 인터페이스
_________17.1.2 품질 속성 테스트
_________17.1.3 구현의 비교
______17.2 서비스와 사용자 인터페이스 분리
_________17.2.1 관심의 분리
_________17.2.2 재사용 가능한 업무 규칙
______17.3 정리

___18장 엔티티와 릴레이션십
______18.1 릴레이션십
_________18.1.1 엔티티와 릴레이션십
_________18.1.2 다중 릴레이션십
_________18.1.3 다른 표현법
______18.2 정리

___19장 대규모 시스템에서의 3인체제
______19.1 대규모 시스템
______19.2 고객 테스트가 꼭 필요하지 않은 경우
_________19.2.1 데이터 변환
_________19.2.2 데이터베이스 변환
______19.3 테스트가 전혀 없을 경우
_________19.3.1 레거시 시스템
______19.4 정리

3부 일반적인 이슈

___20장 업무 가능성, 규칙, 가치
______20.1 업무 역량
______20.2 시나리오 처리
______20.3 업무 규칙 표출
______20.4 다른 업무 가치
______20.5 정리

___21장 테스트 표현
______21.1 고객이 이해 가능한 테이블
______21.2 테이블과 텍스트
______21.3 다중 행동의 구체화
______21.4 복잡한 데이터
______21.5 수정된 테이블 형태
______21.6 정리

___22장 테스트 평가
______22.1 테스트 양상
_________22.1.1 고객이 이해하기 쉬워야 한다
_________21.1.2 맞춤법을 검사해야 한다
_________21.1.3 결과가 항상 동일해야 한다
_________21.1.4 깨지지 않아야 한다
______22.2 테스트 순서
_________22.2.1 작업흐름 테스트
______22.3 테스트 조건
_________22.3.1 관심의 분리
_________22.3.2 테스트 실패
_________22.3.3 테스트 중복
______22.4 구현 이슈 배제
______22.5 기억해야 할 사항들
______22.6 정리

___23장 다른 부분에 테스트 활용
______23.1 인수 테스트의 활용
_________23.1.1 완성도
_________23.1.2 예측 도우미
_________23.1.3 스토리 분할
_________23.1.4 개발자 스토리
______23.2 버그 리포트로서의 테스트
_________23.2.1 원인 분석
_________23.2.2 제품 버그
_________23.2.3 회귀 테스트
______23.3 정리

___24장 테스트 컨텍스트와 도메인 언어
______24.1 유비쿼터스 언어
______24.2 두 개의 도메인
______24.3 정리

___25장 회고와 관점
______25.1 복습
_________25.1.1 프로세스
_________25.1.2 테스트 레이어
_________25.1.3 테스트
_________25.1.4 의사소통
______25.2 장벽
_________25.2.1 모나드
_________25.2.2 이용 불가능한 고객
_________25.2.3 변경
_________25.2.4 리스크
______25.3 이익
______25.4정리

4부 사례 연구

___26장 사례 연구: 은퇴 연금
______26.1 테스트 컨텍스트
______26.2 주 경로 테스트
_________26.2.1 설정
_________26.2.2 이벤트
_________26.2.3 예상 결과
_________26.2.4 구현 이슈
_________26.2.5 관심의 분리
______26.3 업무 가치 추적
______26.4 하나의 예외
_________26.4.1 이벤트
_________26.4.2 예상 결과
______26.5 기타 예외 사항
_________26.5.1 이벤트
_________26.5.2 예상 결과
______26.6 동시에 발생하는 두 개의 예외 상황
_________26.6.1 이벤트
_________26.6.2 예상 결과
______26.7 큰 그림
_________26.7.1 이벤트 테이블
______26.8 상태 전이 테이블
______26.9 정리

___27장 사례 연구: 신호처리
______27.1 너무 시끄럽다
______27.2 소음도
______27.3 개발자 테스트
______27.4 정리

___28장 사례 연구: 도서관 프린트 서버
______28.1 테스트 컨텍스트
______28.2 작업흐름 테스트
______28.3 정리

___29장 사례 연구: 가용성이 높은 플랫폼
______29.1 서버 교환에 대한 테스트 컨텍스트
______29.2 서버 교환에 대한 테스트
______29.3 기술적인 규칙에 대한 테스트
______29.4 정리

5부 기술적인 주제

___30장 ATDD에 적용할 수 있는 것과 그 방법
______30.1 테스트 플랫폼
______30.2 테스트부터 시작하는 내부 설계
______30.3 디바이스 테스팅
______30.4 사용자 인터페이스에서 시작
______30.5 블랙박스 테스팅
______30.6 단위 테스트
______30.7정리

___31장 테스트 설정
______31.1 공통 설정
______31.2 몇 가지 개선 사항
______31.3 테스트 순서
______31.4 영속적인 저장소의 이슈
______31.5 정리

___32장 사례 연구: 이메일 주소
______32.1 테스트 컨텍스트
______32.2 테스트 분할
_________32.2.1 로컬 파트 확인
_________32.2.2 도메인 테스트
_________32.2.3 허용되지 않는 도메인의 테스트
_________32.2.4 연결을 확인하는 테스트
_________32.2.5 검토 테스트
______32.3 정리

부록

___부록A 그밖의 이슈들
______A.1 테스트 컨텍스트
______A.2 고객 예제
_________A.2.1 애매한 인수 테스트
_________A.2.2 인수 테스트 상세
______A.3 요구사항과 인수 테스트
_________A.3.1 요구사항과 테스트 문서화
_________A.3.2 요구사항 분리
_________A.3.3 이슈의 분리
______A.4 랜덤 이벤트를 이용한 시스템 테스트
______A.5 숫자 3의 힘
______A.6 정리

___부록B 업무 가치 예측
______B.1 업무 가치
______B.2 개발자 스토리
______B.3 정리

___부록C 테스트 프레임워크 예제


______C.1 예제
______C.2 Fit 구현
_________C.2.1 설정
_________C.2.2 CD 대여
_________C.2.3 반납
_________C.2.4 CD 종류에 따른 대여 요금
______C.3 Slim-테이블 스타일
_________C.3.1 헤더
_________C.3.2 설정
_________C.3.3 CD 대여
_________C.3.4 반납
_________C.3.5 CD 종류에 따른 대여 요금
______C.4 Slim-Cucumber 스타일
_________C.4.1 설정
_________C.4.2 CD 대여
_________C.4.3 CD 반납
_________C.4.4 시나리오 라이브러리
_________C.4.5 CD 종류에 따른 대여 요금

______C.5 Robot
_________C.5.1 설정
_________C.5.2 CD 대여
_________C.5.3 CD 반납
_________C.5.4 CD 종류에 따른 대여 요금

______C.6 Cucumber
_________C.6.1 CD 대여
_________C.6.1 CD 반납
_________C.6.2 CD 종류에 따른 대여 요금
______C.7 테스트 프레임워크
______C.8 정리



___부록D 테이블의 활용
______D.1 테이블을 이용해 사용자 인터페이스 테스트
______D.2 요구사항 테이블
_________D.2.1 그 외의 테이블
______D.3 품질 속성 요구사항
______D.4 데이터 테이블
______D.5 정리

___부록E ATDD와 화폐 테스트
______E.1 테스트 컨텍스트
______E.2 본래의 테스트
______E.3 인수 테스트 접근 방법
______E.4 정리

___부록F 연습문제
______F.1 계산기
_________F.1.1 테스트 생성
______F.2 좀 더 많은 연습문제
_________F.2.1 샘의 CD 대여점
_________F.2.2 삼각형 연습문제
_________F.2.3 파일 복사 연습문제

___참고문헌과 참고자료
_________참고자료
_________참고문헌
___에필로그
______육하원칙: 누가, 무엇을, 언제, 어디서, 왜, 어떻게
_________그 밖의 사항
_________법적 공지
______다른 이들의 경험
_________재작업이 60%에서 20%로 감소했다
_________처음으로 동작한 작업흐름
_________의사소통 오류의 감소
_________시간 절약
_________올바른 업무 규칙 얻어내기
_________테스트를 위한 시나리오
_________인수 테스트와 단위 테스트
_________게임 변경
_________더욱 밀접해진 교차 기능 팀 통합, 산뜻한 시각 스토리 완성 기준, 자동화로 감소된 테스트 시간
_________여러분의 이야기는 어떠한가?
______정리