상세정보

2014년 세종도서 학술부문 선정도서

완벽을 추구하는 구글의 혁신적인 소프트웨어 테스팅 방법을 배우고 싶은가? 테스팅 전문가인 제임스 휘태커를 비롯한 저자진이 구글 현직 테스팅 전문가들과의 사내 인터뷰를 통해 구글의 소프트웨어 테스팅 기법과 도구와 최신 사례를 소개하고, 품질을 중시하는 구글의 테스팅 문화와 철학은 무엇인지를 낱낱이 밝힌다. 위험 분석, 테스트 계획, 탐험적 테스트, 수동 테스팅, 자동 테스팅, 테스트 인프라스트럭처, 인수 테스팅 등에 관한 매우 실무적이고 실용적인 기술과, 유용한 피드백을 얻고, 이슈를 추적하기 위한 툴의 선택과 제작법을 알려준다.

소프트웨어 개발은 어렵다. 소프트웨어 테스트 역시 어렵다. 웹 전반에 걸쳐 개발과 테스트에 대한 이야기를 할라치면 누구든 구글을 언급한다. 구글과 같은 회사들이 대규모의 테스팅을 어떻게 처리하는지 인터넷에서 관심 있게 찾아본 적이 있다면 여러분은 제대로 된 책을 만난 것이다.

매일 구글은 분산된 수백만의 소스 파일들에서 수억의 코드 라인을 테스트하고 릴리스한다. 수십억의 빌드 작업이 수백의 자동화된 테스트를 즉각적으로 수행해 매일 브라우저에서 수억 번 동작한다. 한 해 동안 운영 시스템에서 빌드, 테스트, 릴리스가 이뤄진다. 브라우저는 매일 빌드되고, 웹 애플리케이션은 끊임없이 출시, 배포된다. 2011년에는 구글플러스(Google+)의 100개 기능이 불과 100일 만에 출시됐다.

이것이 구글의 규모이자 구글의 스피드로, 곧 웹 그 자체의 규모와 매한가지이며, 바로 이 책에서 설명하는 테스팅 솔루션이다. 이 책에서는 이러한 인프라스트럭처가 어떻게 계획되고 구현되고 유지 보수되는지 설명한다. 또한 개념과 구현을 개발하는 데 중요한 수많은 인력에 대해 소개하고, 결과를 만들어내는 인프라스트럭처에 대해 이야기한다.

하지만 이 방법만이 유일한 길은 아니다. 구글이 오늘날 여기까지 온 과정은 우리가 테스트를 할 때 사용했던 많은 기술들만큼 흥미롭다. 6년 전 구글은 우리가 일해본 여러 회사들과 크게 다르지 않았다. 테스트는 주요 핵심 영역이 아니었다. 테스팅 분야에서 일하는 사람들은 별다른 인정을 받지 못했고 야근도 잦았다. 테스트는 수작업이 매우 많은 업무였기에, 자동화에 소질이 있는 사람들은 좀 더 큰 '영향'을 미칠 수 있는 개발에 재빨리 투입됐다. 오늘날 구글에서 '생산성 혁신(Engineering Productivity)' 팀은 엔지니어링보다 영웅적인 활동을 선호하는 기업 문화, 그리고 테스팅에 대한 편견을 극복해야만 했다. 오늘날 구글 테스터들은 개발자들과 동일한 수준의 연봉을 받고, 보너스와 승진 기회도 동등하게 주어진다. (제품, 다양성, 수익 측면에서) 괄목할 만한 구글의 성장과 함께 테스터 직군이 형성되고 테스팅 문화가 살아났으며 구조적인 조직 재구성이 이뤄지자, 다른 기업들은 구글의 행로를 밟아나가기에 이르렀다. 이제 테스팅을 제대로 완료할 수 있고 상품화 팀과 회사 경영진은 테스팅 팀에 모두 감사하게 될 것이다.

웹에서 미래를 발견하고 돈을 벌기를 원하는 회사라면 이 책에서 설명하는 테스팅 기술과 조직 구조는 더더욱 유용할 것이다. 그러한 회사들은 이 책을 꼭 읽어보길 바란다.


★ 이 책의 구성 ★

이 책은 직무 역할에 기반을 두고 작성됐다. 1장에서는 구글 품질 프로세스에 대한 모든 개념, 프로세스, 복잡다단한 사항들에 대해 설명하고, 모든 직군을 살펴본다. 1장은 꼭 읽어야 한다.

나머지 각 장은 어떤 방식으로 읽어도 무방하다. 우리는 먼저 테스트 역할에서 SET 또는 소프트웨어 엔지니어에 대해 이야기한다. 그것이 현재 구글 테스팅의 시작이기 때문이다. SET(테스트 소프트웨어 엔지니어)는 기술적인 테스터이고, 2장에서 다루는 자료들은 기술적인 내용이지만, 누구나 주요 개념을 잡을 수 있는 수준으로 작성됐다. 3장에서는 다른 주요 테스팅 역할인 TE, 즉 테스트 엔지니어에 대해 설명했다. TE의 업무가 매우 방대하고 구글에서 TE는 제품 주기에 많은 역할을 하기 때문에 3장은 매우 길다. TE는 기존의 많은 테스터들이 상상할 수 있는 친숙한 역할로, 이 책을 읽는 대부분의 독자들이 적용할 수 있고, 책에서 가장 많이 읽히는 부분일 것이다.

4장에서는 테스트 관리와 구글 테스트 역사에서 중요한 역할을 하거나 구글 제품에서 핵심 역할을 한 구글의 핵심 인재들과의 인터뷰를 다룬다. 이 인터뷰들은 구글과 비슷한 테스팅 프로세스나 팀을 만들고 싶은 사람들에게 매우 흥미로운 내용일 것이다.

5장은 관심이 있는 독자라면 절대 놓치지 말아야 할 부분이다. 저자 제임스 휘태커는 구글 테스팅이 꾸준히 발전하는 방법에 대해 통찰력을 제공하고, 구글 및 대기업이 가야 할 테스팅 방향에 대해 이야기한다. 저자의 큰 통찰력을 얻을 수 있을 것이며, 조금은 충격을 받을지도 모르겠다.


★ 이 책에 쏟아진 각계의 찬사 ★

제임스 휘태커는 테스팅을 하면서 발생하는 이슈들에 대해 오랜 경험을 갖고 있다. 향후 클라우드로의 변화가 진행되는 10년 동안, 이 책은 단순히 구글 직원들만 읽을 것이 아니라 이 분야에서 경쟁력을 갖추고 의미 있는 성과를 이루기 원하는 모든 테스터를 위한 책이다.
- 샘 구켄하이머(Sam Guckenheimer) / 마이크로소프트 비주얼 스튜디오 전략 팀의 프로덕트 오너

구글은 수동 테스팅 활동과 자동화 테스팅을 혼합하고, 내부와 외부의 자원을 융합하고 있다. 최근에는 내부적인 활동을 보완하기 위해 외부 테스팅 기법까지도 개척하며 앱 테스팅 영역에서 꾸준히 혁신기업 역할을 해오고 있다. 혁신에 대한 욕구를 통해 구글은 새로운 문제를 해결하고 더 나은 앱을 만드는 데 박차를 가하고 있다.
이 책에서 제임스 휘태커는 빠르게 변화하는 앱 테스팅 세계에서 성공하기 위한 구글의 청사진을 제공한다.
- 도란 루베니(Doron Reuveni) / uTest의 CEO이자 창립자

이 책은 일일 릴리스부터 헤드업 디스플레이까지의 모든 판도를 바꿀 것이다. 제임스 휘태커는 미래의 소프트웨어 회사에서 표준으로 자리잡을 테스팅에 대해 전산학적으로 접근했다. 또한 우리 구글에서 사용한 프로세스와 기술 혁신에 대해 사실에 기반을 두고 재미있게 썼다. 소프트웨어 개발과 관련된 사람이라면 누구라도 꼭 읽어봐야 할 책이다.
- 마이클 바흐만(Michael Bachman) / 구글 애드센스?디스플레이 팀 수석 엔지니어 매니저

저자는 구글의 테스트 공학 사례들에 대한 마법을 글로 적어서 현대판 소프트웨어 테스팅의 카마수트라를 집필했다.
- 알베르토 사보이아(Alberto Savoia) / 구글의 엔지니어링 디렉터

클라우드에 코드를 배포하고, 많은 고객들이 행복할 수 있는 고품질의 제품을 전달할 전략을 세우길 원한다면 이 책에서 제시하는 방법들을 연구하고 심각하게 고민해봐야 한다.
- 필 왈리고라(Phil Waligora) / 세일즈포스닷컴(Salesforce.com)

제임스 휘태커는 테스팅 분야에서 많은 이들의 멘토이자 영감을 주는 사람이다. 그의 공헌이 없었더라면 지금의 기술이나 기법들도 없었을 것이다. 나는 아직도 그의 추진력과 열정, 유머에 경외심을 표한다. 그는 IT 업계의 커다란 산이며, 이 책은 IT에 종사하는 사람이라면 누구나 읽어봐야만 하는 필독서다.
- 스튜어트 녹커스(Stewart Noakes) / 영국의 TCL Group Ltd. 회장

나는 마이크로소프트에서 제임스 휘태커와 함께 근무했었고, 지금도 함께 근무할 때의 그를 그리워하지만, 구글에서도 훌륭한 일을 할 것이라고 생각했다. 제임스, 제이슨 아본, 제프 카롤로는 혁신적인 테스팅 아이디어, 실제 사례, 그리고 구글 테스팅 장비에 대한 통찰 등을 이 책에 담았다. 테스팅과 품질에 대한 구글의 접근법이 궁금한 사람이나 테스팅에 대한 새로운 아이디어를 얻기 바라는 마음이 조금이라도 있다면 이 책에서 많은 것을 얻을 수 있을 것이다.
- 앨런 페이지(Alan Page) / 마이크로소프트 엑스박스 팀, 『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다』의 저자


★ 저자 서문 ★

패트릭 코플랜드가 이 책을 쓰자고 제안했을 때 망설였는데, 역시 내 생각이 맞았다. 사람들은 내가 이 책을 쓰기에 가장 적합한 구글러인지에 대한 의문을 품었고(그들은 그랬다), 정말 많은 사람들이 관여하고 싶어 했다(이 또한 사실이다). 하지만 의문의 주된 이유는, 이전에 내가 저술한 모든 책들이 초보자를 위한 책이었기 때문이었다.

?How to Break? 시리즈나 『탐색적 테스팅(Exploratory Testing)』 책들은 세부적이고 완결된 내용이었다. 그러나 이 책은 달랐다. 독자들은 이 책을 한 번에 읽고 끝낼 수도 있겠지만, 구글이 테스팅 사례를 구성하는 크고 작은 작업들을 실제로 어떻게 수행했는가에 대한 참고서 이상의 의미를 지닐 수도 있다. 보편적으로, 초보자들보다는 협업하는 환경에서 소프트웨어를 테스트하는 사람들이 구글의 프로세스와 그들이 사용해본 프로세스를 비교할 수 있는 기준을 갖고 있기 때문에, 이 책에서 더 많은 영감을 얻을 것이다. 아마도 숙련된 테스터, 관리자, 경영진이 재빠르게 흥미로운 주제를 찾아 몇몇 특정 작업에 대해 구글이 어떻게 행동하는지에 대해 해당 절들만 읽을 것이다. 그리고 이런 스타일은 그동안 내가 써왔던 저술 스타일은 아니다!

지금까지 출판 경험이 없는 두 명의 저자와 함께 책을 출간하게 됐다. 두 명 모두 매우 훌륭한 엔지니어이고, 나보다 더 오래 구글에서 근무했다. 제이슨 아본의 직함은 테스트 엔지니어지만, 그의 마음가짐은 여느 기업가 못지않고, 이 책의 테스트 엔지니어 장에서 다룬 많은 생각과 툴들에 미친 그의 영향은 엄청나게 크다. 서로의 경험을 교류하면서 우리 둘은 변했다. 제프 카롤로는 개발자에서 테스터로 업무를 변경한 사람이고, 내가 여태까지 만난 중에 최고의 테스트 개발자다. 제프는 '자동화 길을 걸어오면서' 성공한 몇 안 되는 사람 중 하나다. 그의 테스트 코드는 매우 잘 만들어져서 처음 작성한 그 상태 그대로 두어도 추가 수정 없이 어느 팀이나 수행할 수 있게 작성돼 있다.

이 두 명은 매우 뛰어난 사람들이었고, 우리는 이 책을 한 목소리로 쓰기 위해 많은 노력을 쏟았다.

많은 구글러들이 게스트로서 자료를 제공해줬다. 한 명이 작성한 문서와 주제들인 경우, 글 앞머리에 기고자를 밝혔다. 또한 우리가 수행한 테스트 방법에 막대한 영향을 준 여러 명의 핵심 구글러들과 인터뷰를 하기도 했다. 구글 테스팅에 관여했지만 책에서 언급하지 않은 저자는 아마 30명 정도가 될 것이다! 모든 독자들이 모든 인터뷰 내용에 관심을 갖지 않을 수 있으므로, 본문에 내용을 명확하게 언급해 독자들이 읽거나 건너뛸 수 있게 했다.

아낌없이 지원해준 모든 분께 감사를 드리고, 우리가 작성한 내용이 그들이 수행하는 업무보다 부족하다면 어떤 비난도 받아들이겠다. 글만으로는 그들의 뛰어난 재능을 모두 표현하기에는 부족했다.

즐겁게 읽고, 즐겁게 테스트하고, 항상 여러분이 찾고자 하는 버그를 찾고 수정하길 바란다.

- 워싱톤 주 커클랜드에서
제임스 휘태커
제이슨 아본
제프 카롤로

★ 옮긴이의 말 ★

소프트웨어 테스팅 분야는 국내에서는 그동안 중요성이 많이 부각되지 않았고, 전문가도 많이 없는 실정이다. 당연히 컨설팅 받을 만한 곳도 많지 않고 대부분 피상적이거나 교과서적인 테스팅에 거치게 되는 경우가 많았다. 게다가 버그 파악의 많은 부분을 아쉽게도 최종 사용자의 피드백에 의존하고 있기도 하다. 이런 면에서 이 책을 통해 세계 최대의 소프트웨어 회사라 할 수 있는 구글의 고민과 사례를 엿볼 기회가 생겼다는 것은 매우 흥미롭다.

저자들은 테스팅은 이래야만 한다라는 것을 말하고자 하는 것이 아니라, 우리는 이렇게 테스트하고 있다는 것을 말하고 있다. 그래서 어쩌면 기대 했던 것보다는 실망할 수도 있으며, 너무 구글 상황에 맞는 테스트 사례들이라 얻어갈 것이 많지 않다고 느낄 수도 있다.

하지만, 지금 직장이 구글과 비슷한 환경이나 문화가 아니어서 직접적으로 그들의 사례를 적용할 수는 없을 지라도, 고품질의 소프트웨어를 빠르게 릴리스하는 구글의 개발과 테스팅에 관한 아이디어와 사례, 조직 구성으로부터 많은 것들을 배울 수 있을 것이다. 특히, 구글이 어떻게 소프트웨어 테스팅에 관해서 중요하게 다루게 되었는지에 대한 히스토리와 실무자들의 여러 인터뷰들, 어떻게 하기 어려운 테스트들을 테스트 가능하게 만들기 위해 노력했는지에 대한 이야기와 그 결과인 테스트 프레임워크, 툴들, 탐험적 테스팅을 위한 투어 방법론, 10분 테스트 계획법, 크라우드소싱을 이용한 테스팅 등의 이야기를 통해 독자들은 분명 많은 아이디어를 얻어갈 수 있을 것이다.

책을 번역하는 중에 저자 중의 한 명인 제임스 휘태커가 구글을 관두고 다시 전 직장인 마이크로소프트로 돌아갔다. 그는 자신이 입사했던 구글은 직원들에게 혁신의 동기를 부여하는 회사여서 열정적으로 임할 수 있었는데, 자신이 떠나는 구글은 한 가지 목적에만 집중하는 광고회사였다고 블로그에 밝힌 바가 있다. 그가 떠난 이유야 어찌되었든 간에, 그와 구글의 테스팅 전문가들이 그동안 이룩해놓은 테스팅 분야의 성과는 이 책에 고스란히 담겨있다고 할 수 있다.

정보제공 :

추천의 글 = 6
지은이 소개 = 8
감사의 글 = 9
옮긴이 소개 = 12
옮긴이의 말 = 13
들어가며 = 28
1부 3인의 이야기 = 35
 1장 프롤로그 = 37
  1.1. 소프트웨어 개발 방법 = 37
   1.1.1. 첫 번째 방법 = 37
   1.1.2. 두 번째 방법 = 37
   1.1.3. 차이점 = 38
  1.2. 인수 테스트의 중요성 = 38
  1.3. 시스템과 팀 소개 = 41
   1.3.1. 시스템 = 41
   1.3.2. 인물 소개 = 42
  1.4. 정리 = 43
 2장 린과 애자일 = 45
  2.1. 3인체제와 팀 = 45
  2.2. 후 구현 테스트 = 46
  2.3. 느린 피드백보다는 빠른 피드백 = 48
  2.4. 구현 전의 테스트 = 49
  2.5. 린과 애자일의 원리 = 51
  2.6. 정리 = 52
 3장 테스트 전략 = 53
  3.1. 테스트의 종류 = 53
  3.2. 테스트가 수행되는 장소 = 56
  3.3. 테스트 측면 = 57
   3.3.1. 제어점과 관찰점 = 58
   3.3.2. 새로운 테스트는 새로운 요구사항이다 = 58
  3.4. 정리 = 59
 4장 인수 테스트 소개 = 61
  4.1. 업무 규칙 예제 = 61
  4.2. 인수 테스트의 구현 = 64
   4.2.1. 테스트 스크립트 = 64
   4.2.2. 사용자 인터페이스 테스트 = 65
   4.2.3. xUnit 테스트 = 67
   4.2.4. 자동화 인수 테스트 = 68
   4.2.5. 종합 테스트 = 70
  4.3. 테스트 절차 = 70
  4.4. 정리 = 71
 5장 예제 프로젝트 = 73
  5.1. 기획 = 73
   5.1.1. 목표 = 74
   5.1.2. 프로젝트 인수 테스트 = 75
  5.2. 고수준의 요구사항 = 77
   5.2.1. 기능 = 78
   5.2.2. 기능 인수 기준 = 79
  5.3. 정리 = 81
 6장 사용자 스토리 기술 = 83
  6.1. 스토리 = 83
   6.1.1. 기능을 스토리로 분할 = 84
   6.1.2. 역할 = 85
   6.1.3. 역할 속성 = 86
   6.1.4. 페르소나 = 87
   6.1.5. 역할의 스토리 = 88
   6.1.6. 스토리 인수 기준 = 88
   6.1.7. 인수 테스트가 크기를 결정한다 = 90
   6.1.8. 고객 용어 = 91
  6.2. INVEST 기준 = 92
  6.3. 정리 = 94
 7장 시나리오 협업 = 95
  7.1. 사용자 스토리로부터 유스케이스 생성 = 95
   7.1.1. 간단한 유스케이스 = 97
   7.1.2. 예외와 대안 = 98
   7.1.3. 인수 테스트 = 102
   7.1.4. 문서화 = 103
  7.2. 스토리 지도 = 103
  7.3. 개념적인 흐름 = 105
  7.4. 의사소통 = 105
  7.5. 정리 = 108
 8장 테스트 분해 = 109
  8.1. 3인체제의 테스트 생성 = 109
  8.2. 테스트 컨텍스트 = 110
  8.3. 테스트 구조 = 111
   8.3.1. 계산 테이블 = 114
   8.3.2. 데이터 테이블 = 115
   8.3.3. 액션 테이블 = 116
  8.4. 예제 값으로 테스트 = 118
   8.4.1. 요구사항 수정 = 119
   8.4.2. 인수 테스트 수정 = 120
  8.5. 문장에 있는 값으로 테스트 = 122
  8.6. 테스트가 실행 시기와 장소 = 123
  8.7. 정리 = 123
 9장 시나리오 테스트 = 125
  9.1. 예외 시나리오 테스트 = 125
  9.2. 업무 규칙 테스트 = 129
  9.3. 스토리 충돌 문제 = 130
  9.4. 모든 것을 자동화할 수 없다 = 132
  9.5. 다중 레벨 테스트 = 134
  9.6. 사용자 인터페이스 테스트 = 136
  9.7. 목표 검사 = 137
  9.8. 정리 = 138
 10장 사용자 스토리 분할 = 139
  10.1. 인수 테스트가 스토리 분할을 돕는다 = 139
  10.2. 업무 규칙 테스트 = 140
  10.3. 업무 규칙과 스토리 = 145
  10.4. 정리 = 147
 11장 시스템 경계 = 149
  11.1. 외부 인터페이스 = 149
   11.1.1. 상세사항 = 153
  11.2. 외부 인터페이스 테스트 = 155
   11.2.1. 컴포넌트 테스트 = 155
   11.2.2. 테스트 더블과 모의 객체 = 159
  11.3. 진짜와 가짜 = 161
  11.4. 액티비티 스토리 지도 = 162
  11.5. 정리 = 163
 12장 개발 리뷰 = 165
  12.1. 나머지 스토리 = 165
   12.1.1. 사용성 테스트 = 166
   12.1.2. 화면과 상태의 분리 = 167
   12.1.3. 품질 속성 테스트 = 168
   12.1.4. 작업흐름 테스트 = 170
  12.2. 개발 계획 = 171
  12.3. 기획에서 인수까지 = 172
  12.4. 정리 = 172
2부 상세사항 = 173
 13장 분리를 통한 간략화 = 175
  13.1. 복잡한 업무 규칙 = 175
   13.1.1. 분리에 의한 간략화 = 176
   13.1.2. 단순화된 규칙 = 178
  13.2대여 이력 = 179
  13.3. 정리 = 182
 14장 모델과 뷰의 분리 = 183
  14.1. 사용자 인터페이스의 분리 = 183
  14.2. 분리는 테스팅을 쉽게 한다 = 188
  14.3. 정리 = 188
 15장 이벤트, 반응, 상태 = 189
  15.1. 이벤트와 이벤트 테이블 = 189
  15.2. 상태와 상태 전이 = 192
  15.3. 내부 상태와 외부 반응 = 194
   15.3.1. 임시 상태나 영속 상태 = 197
   15.3.2. 젠 질문 = 197
  15.4. 정리 = 197
 16장 개발자 인수 테스트 = 199
  16.1. 컴포넌트 인수 테스트 = 199
   16.1.1. 필드 디스플레이 테스트 = 199
   16.1.2. 테이블 디스플레이 테스트 = 202
  16.2. 정리 = 206
 17장 인터페이스 분리 = 207
  17.1. 서비스 제공자에 대한 테스트 = 207
   17.1.1. 인터페이스 = 208
   17.1.2. 품질 속성 테스트 = 209
   17.1.3. 구현의 비교 = 210
  17.2. 서비스와 사용자 인터페이스 분리 = 212
   17.2.1. 관심의 분리 = 213
   17.2.2. 재사용 가능한 업무 규칙 = 213
  17.3. 정리 = 214
 18장 엔티티와 릴레이션십 = 215
  18.1. 릴레이션십 = 215
   18.1.1. 엔티티와 릴레이션십 = 215
   18.1.2. 다중 릴레이션십 = 217
   18.1.3. 다른 표현법 = 220
  18.2. 정리 = 221
 19장 대규모 시스템에서의 3인체제 = 223
  19.1. 대규모 시스템 = 223
  19.2. 고객 테스트가 꼭 필요하지 않은 경우 = 226
   19.2.1. 데이터 변환 = 226
   19.2.2. 데이터베이스 변환 = 227
  19.3. 테스트가 전혀 없을 경우 = 227
   19.3.1. 레거시 시스템 = 229
  19.4. 정리 = 231
3부 일반적인 이슈 = 233
 20장 업무 가능성, 규칙, 가치 = 235
  20.1. 업무 역량 = 235
  20.2. 시나리오 처리 = 236
  20.3. 업무 규칙 표출 = 237
  20.4. 다른 업무 가치 = 238
  20.5. 정리 = 239
 21장 테스트 표현 = 21
  21.1. 고객이 이해 가능한 테이블 = 241
  21.2. 테이블과 텍스트 = 243
  21.3. 다중 행동의 구체화 = 243
  21.4. 복잡한 데이터 = 245
  21.5. 수정된 테이블 형태 = 246
  21.6. 정리 = 247
 22장 테스트 평가 = 249
  22.1. 테스트 양상 = 249
   22.1.1. 고객이 이해하기 쉬워야 한다 = 249
   21.1.2. 맞춤법을 검사해야 한다 = 250
   21.1.3. 결과가 항상 동일해야 한다 = 250
   21.1.4. 깨지지 않아야 한다 = 250
  22.2. 테스트 순서 = 251
   22.2.1. 작업흐름 테스트 = 252
  22.3. 테스트 조건 = 252
   22.3.1. 관심의 분리 = 253
   22.3.2. 테스트 실패 = 254
   22.3.3. 테스트 중복 = 254
  22.4. 구현 이슈 배제 = 256
  22.5. 기억해야 할 사항들 = 256
  22.6. 정리 = 257
 23장 다른 부분에 테스트 활용 = 259
  23.1. 인수 테스트의 활용 = 259
   23.1.1. 완성도 = 259
   23.1.2. 예측 도우미 = 260
   23.1.3. 스토리 분할 = 260
   23.1.4. 개발자 스토리 = 261
  23.2. 버그 리포트로서의 테스트 = 261
   23.2.1. 원인 분석 = 262
   23.2.2. 제품 버그 = 263
   23.2.3. 회귀 테스트 = 263
  23.3. 정리 = 263
 24장 테스트 컨텍스트와 도메인 언어 = 265
  24.1. 유비쿼터스 언어 = 265
  24.2. 두 개의 도메인 = 267
  24.3. 정리 = 268
 25장 회고와 관점 = 269
  25.1. 복습 = 269
   25.1.1. 프로세스 = 270
   25.1.2. 테스트 레이어 = 270
   25.1.3. 테스트 = 271
   25.1.4. 의사소통 = 273
  25.2. 장벽 = 273
   25.2.1. 모나드 = 273
   25.2.2. 이용 불가능한 고객 = 274
   25.2.3. 변경 = 274
   25.2.4. 리스크 = 275
  25.3. 이익 = 275
  25.4. 정리 = 277
4부 사례 연구 = 279
 26장 사례 연구: 은퇴 연금 = 281
  26.1. 테스트 컨텍스트 = 281
  26.2. 주 경로 테스트 = 282
   26.2.1. 설정 = 282
   26.2.2. 이벤트 = 283
   26.2.3. 예상 결과 = 284
   26.2.4. 구현 이슈 = 284
   26.2.5. 관심의 분리 = 284
  26.3. 업무 가치 추적 = 285
  26.4. 하나의 예외 = 285
   26.4.1. 이벤트 = 286
   26.4.2. 예상 결과 = 287
  26.5. 기타 예외 사항 = 287
   26.5.1. 이벤트 = 287
   26.5.2. 예상 결과 = 288
  26.6. 동시에 발생하는 두 개의 예외 상황 = 289
   26.6.1. 이벤트 = 289
   26.6.2. 예상 결과 = 290
  26.7. 큰 그림 = 290
   26.7.1. 이벤트 테이블 = 291
  26.8. 상태 전이 테이블 = 291
  26.9. 정리 = 293
 27장 사례 연구: 신호처리 = 295
  27.1. 너무 시끄럽다 = 295
  27.2. 소음도 = 295
  27.3. 개발자 테스트 = 297
  27.4. 정리 = 298
 28장 사례 연구: 도서관 프린트 서버 = 299
  28.1. 테스트 컨텍스트 = 299
  28.2. 작업흐름 테스트 = 300
  28.3. 정리 = 305
 29장 사례 연구: 가용성이 높은 플랫폼 = 307
  29.1. 서버 교환에 대한 테스트 컨텍스트 = 307
  29.2. 서버 교환에 대한 테스트 = 308
  29.3. 기술적인 규칙에 대한 테스트 = 310
  29.4. 정리 = 312
5부 기술적인 주제 = 313
 30장 ATDD에 적용할 수 있는 것과 그 방법 = 315
  30.1. 테스트 플랫폼 = 315
  30.2. 테스트부터 시작하는 내부 설계 = 316
  30.3. 디바이스 테스팅 = 318
  30.4. 사용자 인터페이스에서 시작 = 319
  30.5. 블랙박스 테스팅 = 320
  30.6. 단위 테스트 = 320
  30.7. 정리 = 321
 31장 테스트 설정 = 323
  31.1. 공통 설정 = 323
  31.2. 몇 가지 개선 사항 = 325
  31.3. 테스트 순서 = 326
  31.4. 영속적인 저장소의 이슈 = 327
  31.5. 정리 = 328
 32장 사례 연구: 이메일 주소 = 329
  32.1. 테스트 컨텍스트 = 329
  32.2. 테스트 분할 = 330
   32.2.1. 로컬 파트 확인 = 331
   32.2.2. 도메인 테스트 = 333
   32.2.3. 허용되지 않는 도메인의 테스트 = 335
   32.2.4. 연결을 확인하는 테스트 = 336
   32.2.5. 검토 테스트 = 336
  32.3. 정리 = 337
부록 = 339
 부록 A. 그밖의 이슈들 = 341
  A.1. 테스트 컨텍스트 = 341
  A.2. 고객 예제 = 342
   A.2.1. 애매한 인수 테스트 = 342
   A.2.2. 인수 테스트 상세 = 343
  A.3. 요구사항과 인수 테스트 = 343
   A.3.1. 요구사항과 테스트 문서화 = 344
   A.3.2. 요구사항 분리 = 345
   A.3.3. 이슈의 분리 = 345
  A.4. 랜덤 이벤트를 이용한 시스템 테스트 = 346
  A.5. 숫자 3의 힘 = 346
  A.6. 정리 = 346
 부록 B. 업무 가치 예측 = 347
  B.1. 업무 가치 = 347
  B.2. 개발자 스토리 = 350
  B.3. 정리 = 351
 부록 C. 테스트 프레임워크 예제 = 353
  C.1. 예제 = 353
  C.2. Fit 구현 = 354
   C.2.1. 설정 = 354
   C.2.2. CD 대여 = 355
   C.2.3. 반납 = 356
   C.2.4. CD 종류에 따른 대여 요금 = 357
  C.3. Slim-테이블 스타일 = 357
   C.3.1. 헤더 = 358
   C.3.2. 설정 = 358
   C.3.3. CD 대여 = 359
   C.3.4. 반납 = 360
   C.3.5. CD 종류에 따른 대여 요금 = 361
  C.4. Slim-Cucumber 스타일 = 361
   C.4.1. 설정 = 362
   C.4.2. CD 대여 = 362
   C.4.3. CD 반납 = 362
   C.4.4. 시나리오 라이브러리 = 363
   C.4.5. CD 종류에 따른 대여 요금 = 364
  C.5. Robot = 365
   C.5.1. 설정 = 365
   C.5.2. CD 대여 = 366
   C.5.3. CD 반납 = 366
   C.5.4. CD 종류에 따른 대여 요금 = 367
  C.6. Cucumber = 367
   C.6.1. CD 대여 = 368
   C.6.2. CD 반납 = 368
   C.6.3. CD 종류에 따른 대여 요금 = 368
  C.7. 테스트 프레임워크 = 369
  C.8. 정리 = 369
 부록 D. 테이블의 활용 = 371
  D.1. 테이블을 이용해 사용자 인터페이스 테스트 = 371
  D.2. 요구사항 테이블 = 374
   D.2.1. 그 외의 테이블 = 375
  D.3. 품질 속성 요구사항 = 376
  D.4. 데이터 테이블 = 377
  D.5. 정리 = 377
 부록 E. ATDD와 화폐 테스트 = 379
  E.1. 테스트 컨텍스트 = 379
  E.2. 본래의 테스트 = 380
  E.3. 인수 테스트 접근 방법 = 382
  E.4. 정리 = 385
 부록 F. 연습문제 = 387
  F.1. 계산기 = 387
   F.1.1. 테스트 생성 = 389
  F.2. 좀 더 많은 연습문제 = 390
   F.2.1. 샘의 CD 대여점 = 390
   F.2.2. 삼각형 연습문제 = 390
   F.2.3. 파일 복사 연습문제 = 390
참고문헌과 참고자료 = 393
 참고자료 = 393
 참고문헌 = 400
에필로그 = 405
 육하원칙: 누가, 무엇을, 언제, 어디서, 왜, 어떻게 = 405
  그 밖의 사항 = 405
  법적 공지 = 406
 다른 이들의 경험 = 406
  재작업이 60％에서 20％로 감소했다 = 406
  처음으로 동작한 작업흐름 = 407
  의사소통 오류의 감소 = 408
  시간 절약 = 409
  올바른 업무 규칙 얻어내기 = 411
  테스트를 위한 시나리오 = 411
  인수 테스트와 단위 테스트 = 412
  게임 변경 = 414
  더욱 밀접해진 교차 기능 팀 통합, 산뜻한 시각 스토리 완성 기준, 자동화로 감소된 테스트 시간 = 416
  여러분의 이야기는 어떠한가? = 416
 정리 = 417
찾아보기 = 419