Top

린 애자일 기법을 활용한 테스트 주도 개발 [협업을 통한 더 나은 소프트웨어 만들기]

  • 원서명Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration (ISBN 9780321714084)
  • 지은이케네스 퍼그
  • 옮긴이이주형, 제갈호준
  • ISBN : 9788960775619
  • 35,000원
  • 2014년 05월 29일 펴냄
  • 페이퍼백 | 428쪽 | 188*250mm
  • 시리즈 : 소프트웨어 테스팅, 애자일

책 소개

요약

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

이 책에서 다루는 내용

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

이 책의 구성

1부: 고객, 개발자, 테스터의 3인 체제가 소프트웨어 시스템을 만드는 이야기를 다룬다. 1부에서는 인수 테스트가 어떻게 프로젝트 기획부터 각 사용자 스토리에 이르는 전체 프로세스에 녹아들 수 있는지를 보여준다.

2부: 인수 테스트를 분해하여 세세히 다룬다.

3부: 테스트 표현(test presentation)과 평가(evaluation)라는 일반적인 주제에 대해 다룬다.

4부: 실제 상황에 대한 사례 연구를 다룬다. 일부 상황은 관련이 있는 부분만을 보여주기 위해서 간략화시켰다.

5부: 테스트 설정(Test Setup)을 어떻게 다루는지 등과 같은 좀 더 기술적인 주제에 관해 다룬다.

6부: 업무 가치와 테스트 자동화 같은 추가적인 주제를 부록에 싣는다.

ATDD에 대한 요약과 이에 대한 장점을 빠르게 익히고자 하는 독자는 ’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에서 양질의 제품을 생산하기 위해서는 실제 테스트할 수 있을 만큼의 명확한 요구사항이 있어야 한다.

예를 들어 이 책이 여러분이 원하는 것을 만족시켜 준다는 걸 판단할 기준이 있는가? 이 책을 다 읽었을 때 어떻게 이 책이 당신의 기준들을 만족시켰는가? 이 책은 독자가 원하는 앞서 질문들에 대한 구현 방법을 보여준다. 여러분은 이미 이 책을 읽는 중이기 때문에 이 책의 인수 테스트 기준에 영향을 끼칠 기회가 없을 것이므로, 독자가 필요로 하는 기준이 무엇인지 다음과 같이 정리해봤다.

영어 수업에서 선생님은 육하원칙(누가, 무엇을, 언제, 어디서, 왜, 어떻게)을 강조한다. 그래서 이 책도 다음과 같이 육하원칙 아래에 그 기준을 만들어봤다.

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

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

저자 소개

케네스 퍼그(Ken Pugh)

25년 이상 소프트웨어 분야에 종사했다. 이전에는 퍼그킬린(Pugh-Killeen) 협회의 학장이었으며, 넷 오브젝티브스(Net Objectives)의 펠로우(fellow) 컨설턴트를 맡고 있다. 레이더 추적장치부터 금융 분석에 관련된 애플리케이션까지 다양한 분야의 소프트웨어를 개발했다. 요구사항 수집부터 테스팅까지 전 분야를 다루어봤고, 21세기에 들어서면서부터는 린과 애자일 프로세스를 도입해 그의 팀원들과 좀 더 효율적으로 소프트웨어를 만들어보려고 노력했다. 다양한 국제 컨퍼런스에서 연설을 한 경험이 있으며, 전 세계에 걸쳐 컨설팅과 강연을 하고 다양한 기술 분야의 주제를 다뤘다. 이 책은 그의 7번째 책이다. 2006년에 그가 집필한 『프리팩토링(Prefactoring)』은 졸트 상을 수상했다. 여가시간에는 스노우보드나 윈드서핑, 캠핑을 즐긴다. 1997년부터 2003년에는 애팔래치아 자연 산책로를 횡단했다.

옮긴이의 말

“이건 사양이 정해졌어야 하는데…” 프로젝트 관리자나 개발자, 또는 품질보증담당자로 테스트를 진행해본 경험이 있는 사람이라면, 소프트웨어 테스트를 진행하는 중에 사양이 정해지지 않아서 곤란했던 경험이 한 번씩은 있을 것이다. 이러한 경험이 있다면 꼭 이 책을 읽어보기를 권한다.

개인적으로 애자일, 특히 테스팅에 관심이 많아서 이 책의 번역 제의가 들어 왔을 때, 선뜻 번역을 맡겠다고 이야기했다. 하지만, 번역을 진행하고 책을 꼼꼼히 읽으면서 이 책은 굳이 애자일에 관심이 없더라도, 소프트웨어 개발과 관련된 업무를 하고 있는 사람이라면 한 번쯤 읽어볼 만하다고 생각하게 되었다. 이 책은 요구사항을 결정해주는 고객과 이를 기반으로 소프트웨어를 구현하고 검증해야 하는 개발자와 테스터 간의 ‘긴밀하고 타이트한 협력’과 ‘빠른 피드백’을 강조하기 위해서 ‘린 애자일(Lean Agile)’이라는 단어를 붙인 듯 하다.

책의 내용은 가상 인물인 샘의 CD 대여점에서 사용할 시스템을 만들어가는 이야기인데, 소프트웨어 시스템을 구축하면서 어떻게 테스트 가능한 요구사항을 도출하는지와 어떤 방식으로 좀 더 명확하게 이를 이끌어내고 정리할 수 있는지를 아주 실질적이고 쉬운 예로 보여준다. 실제로 번역을 진행하면서, “아, 이런 부분은 이렇게 후배사원들에게 설명해주면 좋겠구나”라든가, “개발자들에게 명확한 요구사항의 중요성을 이런 식으로 설명할 수 있겠구나”라고 생각한 부분들이 종종 있었다. 특히 요구사항을 표로 정리하고, 흔히 테스팅 분야에서 이야기하는 결정테이블(decision table) 형태로 표현하고 이를 분리하며 간략화해가는 내용 등은 실제 업무에서 큰 도움이 될 것이라고 생각한다.

옮긴이 소개

이주형

카이스트 소프트웨어 대학원 석사 과정을 졸업했으며, 현재는 삼성전자 가전 사업부 SE파트에서 책임연구원으로 재직 중이다. 주요 관심 분야는 요구공학, 소프트웨어 테스팅이다. 에이콘출판사에서 펴낸 『엔터프라이즈급 애자일 방법론』(2008), 『구글은 소프트웨어를 어떻게 테스트하는가』(2013)를 공역했다.

제갈호준

아이오와 주립대에서 컴퓨터 사이언스 박사 학위를 받고, 삼성전자 무선사업부에서 타이젠 플랫폼TIZEN PLATFORM을 개발하고 있다. 주요 관심 분야는 플랫폼 개발, 아키텍처, 오픈 소스, 자동화 테스팅이다. 에이콘출판사에서 펴낸 『SWT/JFACE 인 액션』(2006), 『엔터프라이즈급 애자일 방법론』(2008), 『구글은 소프트웨어를 어떻게 테스트하는가』(2013) 등을 공역했다.

목차

목차
  • 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%로 감소했다
        • 처음으로 동작한 작업흐름
        • 의사소통 오류의 감소
        • 시간 절약
        • 올바른 업무 규칙 얻어내기
        • 테스트를 위한 시나리오
        • 인수 테스트와 단위 테스트
        • 게임 변경
        • 더욱 밀접해진 교차 기능 팀 통합, 산뜻한 시각 스토리 완성 기준, 자동화로 감소된 테스트 시간
        • 여러분의 이야기는 어떠한가?
      • 정리

도서 오류 신고

도서 오류 신고

에이콘출판사에 관심을 가져 주셔서 고맙습니다. 도서의 오탈자 정보를 알려주시면 다음 개정판 인쇄 시 반영하겠습니다.

오탈자 정보는 다음과 같이 입력해 주시면 됩니다.

(예시) p.100 아래에서 3행 : '몇일'동안 -> 며칠동안