소프트웨어 테스트 자동화

1장 애자일 팀의 테스트 자동화 여행: 첫 번째 해
___1.1 케이스 스터디의 배경
______1.1.1 문제
______1.1.2 목표
___1.2 팀 전체의 헌신
___1.3 자동화 전략 설정
______1.3.1 테스트가 용이한 아키텍처
______1.3.2 빌드 프로세스 구축
______1.3.3 테스팅 기반 생성: GUI 스모크 테스트
______1.3.4 단위 테스트 단계의 개발 추진
___1.4 FitNesse를 사용하여 GUI 뒤 단의 테스트에 ATDD 적용하기
______1.4.1 인메모리 테스트
______1.4.2 데이터베이스를 이용한 테스트
______1.4.3 FitNesse 테스트의 장점
___1.5 점진적 접근법 사용
___1.6 올바른 메트릭
___1.7 성공을 축하하라
___1.8 통합 엔지니어링 스프린트
___1.9 팀의 성공
___1.10 지속적인 개선
___1.11 정리

2장 최적화된 데이터베이스 자동화
___2.1 케이스 스터디의 배경
___2.2 테스트 대상 소프트웨어
___2.3 테스트 자동화 목표
___2.4 사내 테스트 도구 개발
______2.4.1 설정
______2.4.2 리소스 최적화
______2.4.3 보고서
______2.4.4 실패 분석
___ 2.5 결과물
___2.6 자동화 테스트 관리
___2.7 테스트 스위트와 타입
___2.8 현재 모습
___2.9 어려웠던 점과 배운 점
___2.10 테스트 자동화 서적의 가이드 적용
___2.11 정리
___2.12 감사의 말

3장 클라우드로의 이동: TiP의 진화, 프로덕션에서의 지속적인 리그레션 테스팅
___3.1 케이스 스터디의 배경
___3.2 클라우드 환경으로 테스트 전환
______ 3.2.1 TiP 테스트 전략에서 얻고자 한 것
______3.2.2 기본 원칙
___3.3 TiP 구현 방법
___3.4 월간 서비스 리뷰 평가표의 예
______3.4.1 평가표 읽기
______3.4.2 인시던트와 에스컬레이션 보고서로 한 일
___3.5 익스체인지 TiP v2: 윈도우 애저 클라우드로의 TiP 마이그레이션
___ 3.6 배운 점
______3.6.1 파트너 서비스 관련 이슈
______3.6.2 클라우드를 통한 모니터링이 직면한 도전
______3.6.3 TiP 테스트로 발견한 프로덕션 이슈의 예
______3.6.4 결과에서 방해요소 처리에 사용할 집계
______3.6.5 주의할 점
___3.7 정리
___3.8 감사의 말

4장 오토메이터 자동화
___ 4.1 케이스 스터디의 배경: 첫번째 일자리
______4.1.1. 첫 번째 역할: 기술 지원
______4.1.2 QA팀에 합류
___4.2 대단한 아이디어
______4.2.1 지속적인 노력
___4.3 돌파구
______4.3.1 일 시작
______4.3.2 체크포인트 검증
______4.3.3 그 후 어려워진 점
______4.3.4 최후를 예고하는 징조의 시작
___4.4 정리

5장 자동화 엔지니어의 자서전: 메인 프레임에서 프레임워크 자동화까지
___ 5.1 케이스 스터디의 배경
______5.1.1 초기 테스트 자동화: 테스팅 툴과의 첫 만남
______5.1.2 테스트 리플레이에 툴 사용 문제 극복
______5.1.3 메인 프레임 덤 터미널 시스템이 동작하는 방식과 캡처/리플레이 방식이 좋은 아이디어인 이유
______5.1.4 수동 리플레이와 장점
___5.2 메인 프레임 그린스크린 자동화 프로젝트
______ 5.2.1 확대 적용
______5.2.2 자동화 툴 스크립트에 자동화 툴 적용
______5.2.3 성공
______5.2.4 현재 자동화를 원하는 사람
___5.3 메인 프레임과 스크립트 기반 툴의 차이점
______5.3.1 상호작용의 수준
______5.3.1 동기화
_________5.3.1.2 유저 인터페이스 객체
___5.4 새로운 스크립트 기반 툴 사용
______5.4.1 기존 방법으로 새로운 툴의 사용 시도
______5.4.2 툴 프로그래밍
______5.4.3 프레임워크 구축
______5.4.4 프레임워크의 기타 기능
______5.4.5 소프트웨어 테스트 자동화 패러독스: 자동화 테스트에 대한 테스트
___ 5.5 IBM 맥시모의 테스트 자동화
______5.5.1 2010년
______5.5.2 리버레이션 프레임워크
______5.5.3 기술적 도전
_________5.5.3.1 동기화
_________5.5.3.2 UI 객체 인식 문제
_________5.5.3.3 사람과는 다르게 동작하는 툴
_________5.5.3.4 자동화의 3R
______5.5.4 테스트 자동화의 결과
______5.5.5 나머지 조직으로의 자동화 출시
___5.6 정리
___ 5.7 추가자료

6장 첫 번째 프로젝트의 실패와 두 번째 프로젝트의 성공
___ 6.1 케이스 스터디의 배경
___6.2 첫 번째 프로젝트의 실패
___ 6.3 두 번째 프로젝트의 성공
______6.3.1 ROI 추정
______6.3.2 시작
______6.3.3 파일럿 프로젝트의 목표
______6.3.4 첫 번째 달: 실무와 툴의 이해
_________6.3.4.1 공통된 이해와 툴 관련 지식
_________6.3.4.2 문서화
_________6.3.4.3 보험 신청서 관련 지식
_________6.3.4.4 보험 신청서 GUI의 일반 영역과 특정 영역
______6.3.5 전략과 계획
______6.3.6 애자일 테스트 방법론
______6.3.7 첫 번째 기간의 결과
___6.4 다음 기간: 실제 테스팅
______6.4.1 자동화 방향
______6.4.2 이해 관계자의 참여
______6.4.3 동일한 솔루션
______6.4.4 보험 신청서 구조와 QC의 테스트 케이스 구조
______6.4.5 3개월 후 결정의 순간
______6.4.6 파일럿 프로젝트 후의 실제 프로젝트
______6.4.7 운영 환경으로의 실제 릴리즈에 사용된 첫 번째 자동화 테스트
______6.4.8 운영 환경에서의 전체 자동화 테스트
___6.5 정리

7장 종합 정부 시스템 테스트 자동화
___7.1 케이스 스터디의 배경
___7.2 자동화 요구사항
______ 7.3 자동화 테스트 솔루션 ATRT
______ 7.3.1 테스트 대상 시스템에 방해가 되면 안 된다
______7.3.2 운영체제에 독립적이어야 한다
______7.3.3 GUI에 독립적이어야 한다
______7.3.4 디스플레이 기반이거나 디스플레이 기반이 아닌 인터페이스를 모두 자동화 테스트해야 한다
_________7.3.4.1 이클립스
_________7.3.4.2 플러그인
______7.3.5 다중 컴퓨터 네트워크 환경을 처리할 수 있어야 한다
______7.3.6 비 개발자가 도구를 사용할 수 있어야 한다
______7.3.7 자동화된 요구사항 추적 매트릭스를 지원해야 한다
___7.4 자동화 테스트 솔루션 적용
___7.5 정리

8장 디바이스 시뮬레이션 프레임워크
___8.1 케이스 스터디의 배경
___8.2 디바이스 시뮬레이션 프레임워크 탄생
___8.3 DSF 생성
___8.4 자동화 목적
___8.5 케이스 스터디
______8.5.1 USB 펌웨어
______8.5.2 USB 저장소
______8.5.3 비디오 캡처
______8.5.4 DSF의 기타 적용 사례
___8.6 만능 해결책은 없다
___8.7 정리
___8.8 감사의 말

9장 ESA 프로젝트에서의 모델 기반 테스트 케이스 생성
___9.1 케이스 스터디의 배경
___9.2 모델 기반 테스트와 테스트 케이스 생성
______9.2.1 IDATG를 사용한 모델 기반 테스트
_________9.2.1.1 IDATG의 작업 흐름 모델
_________9.2.1.2 테스트 데이터 생성
_________9.2.1.3 테스트 케이스 생성
___9.3 애플리케이션: ESA의 MMUS 소개
______9.3.1 MMUS의 테스트 접근 방법
_________9.3.1.1 주요 전략
_________9.3.1.2 테스트 프레임워크
_________9.3.1.3 일반적인 테스트 시나리오
___9.4 경험과 배운 점
______9.4.1 장점
______9.4.2 모델 기반 테스트의 ROI
_________9.4.2.1 테스트 생성
_________9.4.2.2 테스트 자동화 프레임워크 준비
_________9.4.2.3 테스트 실행
_________9.4.2.4 테스트 유지보수
_________9.4.2.5 전체 소요시간
______9.4.3 문제점과 배운 점
___9.5 정리
______ 9.5.1 요약
______9.5.2 전망
_________9.5.2.1 무작위 테스트 생성
_________9.5.2.2 최근 소식
___9.6 참고문헌
___9.7 감사의 말

10장 10년간 계속되는 프로젝트
___10.1 케이스 스터디의 배경: 이전
___ 10.2 매달 자동으로 테스트되는 보험 견적 시스템
______10.2.1 배경: 영국 보험 산업
______10.2.2 참여하게 된 계기
______10.2.3 자동화 선택 이유
______10.2.4 테스트 전략
______10.2.5 테스트 자동화 툴 선택
______10.2.6 테스트 자동화 계획의 의사결정
_________10.2.6.1 테스터의 업무
_________10.2.6.2 자동화 기술자의 업무
______10.2.7 테스트 계획
______10.2.8 추가적으로 발생한 이슈
______10.2.9 한 가지 이야기: 테스터 대 자동화 기술자
______10.2.10 정리
______10.2.11 감사의 말
______ 10.3 현재 상황
___10.4 정리
______10.4.1 테스터와 자동화 기술자 분리
______ 10.4.2 관리자가 기대하는 것
______10.4.3 특정 툴과 벤더로부터 독립

11장 잿더미에서 날아오른 불사조
___11.1 케이스 스터디의 배경
______11.1.1 조직 구조
______11.1.2 비즈니스 도메인
___11.2 불사조의 탄생
___11.3 불사조의 죽음
___11.4 불사조의 부활
______11.4.1 자동화 프로젝트 다시 시작
______11.4.2 사용 편의성 향상
______11.4.3 자동화 업무 가시화 향상
______11.4.4 더 나은 테스트 방법 구현
______11.4.5 효과 계산: 투자 대비 수익
___11.5 불사조의 새로운 삶
______11.5.1 지식 공유
______11.5.2 자동화 프레임워크 테스트 실행 결과 추적
_________11.5.2.1 추적했던 것과 두 가지 주요 효과
_________11.5.2.2 회사 내 다른 파트로부터의 위협
______11.5.3 속도와 사용의 편이성을 고려한 설계
_________11.5.3.1 임의의 테스트를 선택해서 실행하는 능력
_________11.5.3.2 디버그 로그 옵션
_________11.5.3.3 사용자 친화 인터페이스
_________11.5.3.4 테스트 셋업의 자동화
_________11.5.3.5 리그레션 테스트
___11.6 정리

12장 관료의 수레바퀴 자동화
___12.1 케이스 스터디의 배경
______12.1.1 조직
______12.1.2 에이전시 테스트
___12.2 에이전시 자동화
______12.2.1 레코드 앤 플레이백 향상
______12.2.2 상태 점검과 스모커
______12.2.3 어려운 점과 배운 점
___12.3 2000년부터 2008년까지
______12.3.1 메인 프레임 툴의 효과
______12.3.2 웹 방식
______12.3.3 KASA
______12.3.4 어려운 점과 배운 점
______12.3.5 자동화 홍보
___12.4 행성 정렬
______12.4.1 게르손 리뷰
______12.4.2 독립 테스트 프로젝트
______12.4.3 핵심 리그레션 라이브러리 관리 방법론
______12.4.4 여정에서의 현재 위치
___12.5 테스트팀 역량 확대
______12.5.1 컨셉: 스크립트 개발과 비즈니스 지식 결합
______12.5.2 툴: KASA가 DExTA를 만났을 때
___12.6 향후 방향: 여정은 계속된다
______12.6.1 MBT 솔루션
______12.6.2 붙박이 자동화 엔지니어
______12.6.3 조직에서의 리그레션 테스트 접근 방법
______12.6.4 초기에 하는 자동화
___12.7 정리

13장 하드웨어 인터페이스를 사용한 신뢰성 테스팅의 자동화
___13.1 케이스 스터디의 배경
___13.2 즉각적인 조치의 필요성
___13.3 점증적 접근 방법으로 테스트 자동화 시작
___13.4 경영진의 선택
___13.5 테스트 프레임워크 추가 개발
______13.5.1 인크리먼트 2: 테스터용 언어 개발
______13.5.2 인크리먼트 3: 로그 파일 해석
___13.6 배포와 개선된 리포트
___13.7 정리

14장 안드로이드 애플리케이션의 모델 기반 GUI 테스팅
___14.1 케이스 스터디의 배경
______14.1.1 MBT
______14.1.2 경험: 안드로이드 애플리케이션에서 TEMA 사용
______14.1.3 앞으로 이야기할 것
___14.2 TEMA 툴세트에서 MBT
______14.2.1 도메인 한정 툴
______14.2.2 TEMA에서 역할
______14.2.3 TEMA 툴세트
______14.2.4 액션 머신과 정제 머신
______14.2.5 테스트 데이터 정의
______14.2.6 테스트 설정: 테스트 모델과 테스트 모드
______14.2.7 모델로부터 테스트 생성
______14.2.8 예제: SMS 메시지 전송
___14.3 애플리케이션 행위 모델링
______14.3.2 ATS4 앱모델을 사용한 모델링
___14.4 테스트 생성
______14.4.1 최적 경로 알고리즘의 기능과 선택
______14.4.2 최적 경로 알고리즘의 균형
___14.5 연결과 어댑테이션
______14.5.1 키워드를 실행하는 어댑터
______14.5.2 액션 키워드와 검증 키워드
______14.5.3 검증 구현의 어려운 점
______14.5.4 A-Tool 사용과 그에 따른 변경이 필요한 부분
______14.5.5 다른 문제점
___14.6 결과
___14.7 정리
___14.8 감사의 말
___ 14.9 참고 문헌

15장 SAP 비즈니스 프로세스의 테스트 자동화
___15.1 케이스 스터디의 배경
______ 15.1.1 소프트웨어 회사로서 SAP의 특별한 요구사항
_________15.1.1.1 숫자
_________15.1.1.2 소프트웨어 릴리즈와 테스트 스크립트 버전
_________15.1.1.3 기술
_________15.1.1.4 분산 개발
______15.1.2 SAP에서 테스트 자동화 툴
_________15.1.2.1 eCATT 소개
_________15.1.2.2 eCATT의 장점
_________15.1.2.3 eCATT의 한계
___15.2 표준과 성공 사례
______15.2.1 리그레션 테스트 프로세스
______15.2.2 명세서와 설계
______15.2.3 코딩 가이드라인
______15.2.4 코드 인스펙션
______15.2.5 재사용 가이드라인
______15.2.6 체크맨: eCATT의 정적 분석 툴
___15.3 eCATT 사용 예제
______15.3.1 의료 서비스 프로세스용 데이터 기반 자동화 프레임워크
_________15.3.1.1 APT 모델 정의
_________15.3.1.2 테스트 케이스 계산
_________15.3.1.3 eCATT 설계
_________15.3.1.4 결과와 전망
______15.3.2 은행 업무 시나리오의 테스트 자동화 프레임워크
_________15.3.2.1 프레임워크의 효과와 전망
___15.4 정리
___15.5 감사의 말

16장 SAP 구현의 테스트 자동화
___16.1 케이스 스터디의 배경
___16.2 프로젝트의 개요
___16.3 단계 1: 개념 증명
______16.3.1 프로젝트 범위 정의
______16.3.2 기대결과 설정
______16.3.3 테스트 케이스 스크립팅의 시작
___16.4 단계 2: 프로젝트 시작
______16.4.1 승인
______16.4.2 코드 컨벤션과 문서화
______16.4.3 구조화된 접근 방법
______16.4.4 데이터 주도 테스트 케이스
______16.3.5 다국어 지원
______16.4.6 보안 권한 테스팅
___16.5 정리

17장 잘못된 툴의 선택
___17.1 케이스 스터디의 배경
______17.1.1 제품
______17.1.2 개발 팀
______17.1.3 구글에서의 개발 개요
______17.1.4 릴리즈 주기의 개요
___17.2 기존 자동화
______17.2.1 수동 테스트와 더 많은 자동화의 필요성
___17.3 필요한 결정: 새로운 툴 선택 vs 유지보수 노력
______17.3.1 가진 것을 바꿔야만 했던 이유
______17.3.2 에그플랜트의 개요
___ 17.4 에그플랜트를 활용한 진행
______17.4.1 개발 경험
______17.4.2 툴 언어의 사용
______17.4.3 이미지 기반 비교의 문제점
______17.4.4 테스터가 테스트 유지보수를 해야 한다
______17.4.5 지속적인 통합을 사용한 코드 제출
______17.4.6 제출 대기열이 한 일
______17.4.7 에그플랜트 자동화 시도
______17.4.8 에그플랜트 사용 포기
___17.5 에그플랜트 이후의 툴
___17.6 정리
______17.6.1 툴로서의 에그플랜트
______17.6.2 일반적인 경우에서의 테스트 자동화
______17.6.3 현재의 자동화 관련 문제점

18장 마켓 플레이스 시스템의 테스트 자동화: 십 년간 세 개의 프레임워크
___18.1 케이스 스터디의 배경
___18.2 자동화 테스트 프레임워크
______18.2.1 프레임워크 A
______18.2.2 프레임워크 B
______18.2.3 프레임워크 C
___18.3 테스트의 역할
______18.3.1 테스트 엔지니어
______18.3.2 테스트 자동화 아키텍트
______18.3.3 일일 빌드 엔지니어
___18.4 추상화 계층
___18.5 설정
___18.6 비용과 ROI
___18.7 정리

19장 자동화는 리그레션 테스팅에만 국한되는 것이 아니다
___19.1 케이스 스터디의 배경
___19.2 작업 자동화의 두 가지 이야기
______19.2.1 실패한 자동화와 테스터가 좋아진 이유
_________19.2.1.1 두 개의 툴과 실패
_________19.2.1.2 50라인의 코드로 3시간에서 30분으로 단축
_________19.2.1.3 테스터가 좋아진 이유
______19.2.2 테스트 자동화가 아닌 테스트 관련 자동화
___19.3 수동 탐색 테스트를 지원하는 자동화
___19.4 테이터 인터렉션 자동화
___19.5 자동화와 모니터링
______19.5.1 너무 빨리 통과된 테스트
_________19.5.2 잘못된 게 없다면 테스트는 반드시 통과해야 했다
___19.6 간단한 툴 조합으로 실환경 부하 시뮬레이션
___19.7 정리
___19.8 참고문헌

20장 의료기기용 소프트웨어와 절실했던 소프트웨어 테스트 자동화
___20.1 케이스 스터디의 배경
______20.1.1 의료기기의 배경
______20.1.2 회사의 배경
______20.1.3 소프트웨어 테스트 자동화와 관련된 의료기기의 제약사항과 세부사항
______ 20.1.4 몇 가지 프로젝트와 시나리오
___20.2 각 프로젝트에 대한 여러 가지 접근 방법의 비교
______20.2.1 테스트 목적 정의: 핵심 기능에 집중
______20.2.1.1 의료기기 대상 테스트 범위에 적합한 일반적인 사례
_________20.2.1.2 대단한 기대
______20.2.2 테스트 흐름
_________20.2.2.1 자동화 시기: 벌레는 일찍 일어난 새가 잡을 수도 있지만, 치즈는 두 번째 쥐가 얻는다
_________20.2.2.2 자동화 초기: 자동화 대상과 비대상 기준
_________20.2.2.3 실제 적용
___20.3 HAMLET 프로젝트
___20.4 PHOENIX 프로젝트
______20.4.1 툴
______20.4.2 유지보수와 마이그레이션 이슈
_________20.4.2.1 유지보수의 한계점
_________20.4.2.2 제한된 자동화 테스트 유지보수 진행 방법
_________20.4.2.3 기법
___20.5 DOITYOURSELF 프로젝트
______20.5.1 툴
______20.5.2 유지보수와 툴 검증 이슈
______20.5.3 기법
______20.5.4 예상하지 못한 문제와 해결책
___20.6 MINIWEB 프로젝트
______20.6.1 툴
______20.6.2 유지보수
______20.6.3 기법
______20.6.4 예상하지 못한 문제와 해결책
___20.7 테스트 실행
___20.8 결과 보고
___20.9 정리
______20.9.1 프로젝트 회고
______20.9.2 다르게 할 수 있는 부분
______20.9.3 향후 계획

21장 수동 테스팅 지원을 통한 은밀한 자동화
___21.1 케이스 스터디의 배경
___21.2 기술적 해결책
______21.2.1 커맨드 기반 테스팅
______21.2.2 ISS 테스트 스테이션
_________21.2.2.1 ITS 클라이언트
_________21.2.2.2 ITS 엔진
___21.3 ISS 테스트 스테이션을 활용한 테스트 자동화 구현
______21.3.1 자동화 프로세스
_________21.3.1.1 전제 조건
_________21.3.1.2 테스트 스위트 준비
_________21.3.1.3 테스트 실행
___21.4 테스트 자동화 구현
______21.4.1 기존 절차
______21.4.2 취약점
___21.5 수동 테스트 지원
______21.5.1 구현된 기능
______21.5.2 현재 프레임워크에 구현되지 않은 기능
___21.6 새로운 수동 테스트 프로세스
______21.6.1 프레임워크로 마이그레이션
______21.6.2 프레임워크를 활용한 수동 테스트
_________21.6.2.1 테스트 케이스 개발과 유지보수
_________21.6.2.2 테스트 실행
_________21.6.2.3 결함 추적
_________21.6.2.4 통계
______21.6.3 수동 테스트의 자동화
_________21.6.3.1 개발
___21.7 정리
______21.7.1 시작 단계
______21.7.2 2010년의 상황
______21.7.3 다음 단계
___21.8 참고문헌

22장 이식성 테스팅의 가치를 더해주는 테스트 자동화
___22.1 케이스 스터디의 배경
___22.2 이식성 테스트
___22.3 해결책으로서 양쪽 진영의 결합
______22.3.1 LA-PORTA
______22.3.2 가상화 제품
______22.3.3 VixCOM
______22.3.4 테스트 자동화 툴
______22.3.5 파일 구조
___22.4 정리
___22.5 감사의 말

23장 보험 회사에서의 자동화 테스트
___23.1 케이스 스터디의 배경
___23.2 애플리케이션
___23.3 목표
___23.4 작업
______23.4.1 1 단계
______23.4.2 2 단계
______23.4.3 3 단계
______23.4.4 4 단계
___23.5 교훈
______23.5.1 화면 해상도
______23.5.2 더 적은 것이 때로는 더 많은 것이다
___23.6 정리
______23.6.1 가장 큰 성공
______23.6.2 흥분하지 마라

24장 테스트 멍키 대모험
___24.1 케이스 스터디의 배경
___24.2 자동 리그레션 테스팅의 한계
______24.2.1 자동화 리그레션 테스트는 정적이다
______24.2.2 자동화 리그레션 테스트는 단순하다
______24.2.3 자동 테스트의 재초기화
______24.2.4 애플리케이션과 동기화
______24.2.5 변경에 취약하다
___24.3 테스트 멍키
______24.3.1. 특징
______24.3.2 기본 기능
___24.4 테스트 멍키 구현
___24.5 테스트 멍키의 사용
______24.5.1 지표
___24.6 장점과 단점
___24.7 정리
___24.8 참고문헌

25장 NATS에서의 복합 시스템 테스트 자동화
___25.1 케이스 스터디의 배경
______25.1.1 복합 시스템 운영 상황
______25.1.2 테스트 자동화 초기 목표와 제약 사항
___25.2 테스트 실행 툴 통합
___25.3 툴을 위한 파일럿 프로젝트
___25.4 인서비스 모델
___25.5 구현
___25.6 일반적인 스크립트 템플릿
___25.7 배운 점
______25.7.1 일반적인 교훈
______25.7.2 기술적인 교훈
___25.8 정리

26장 자동차 전자 기기 테스팅 자동화
___26.1 케이스 스터디의 배경
___26.2 자동화 프로젝트의 목적
___26.3 자동화 프로젝트의 약력
______26.3.1 첫 번째 툴
______26.3.2 첫 번째 툴의 제약 사항과 차세대 툴의 개발
___26.4 자동화 프로젝트의 결과
___26.5 정리

27장 BHAG, 변경과 테스트의 변신
___27.1 케이스 스터디의 배경
___27.2 설득
______27.2.1 임원진
______27.2.2 개발자의 '왜'
______27.2.3 QA 팀에 권한 부여
_________27.2.3.1 BHAG
_________27.2.3.2 역할의 재정비
_________27.2.3.3 테스트 자동화 리더십 팀
_________27.2.3.4 거듭되는 개선
___27.3 자동화 프레임워크 구축 이야기
______27.3.1 테스트 포인트 생성
______27.3.2 시작
______27.3.3 컨설턴트
______27.3.4 프레임워크의 재구축
___27.4 자동화 프레임워크의 설명
______27.4.1 프레임워크의 모듈
______27.4.2 모듈의 고려 사항
_________27.4.2.1 모듈 규칙
_________27.4.2.2 새로운 모듈
_________27.4.2.3 모듈의 이슈
______27.4.3 스크립트 실행
______27.4.4 실패 캡처 방법
___27.5 테스트 환경
______27.5.1 다중 LAN
______27.5.2 가상 머신
___27.6 지표
______27.6.1 자동화 효과
_________27.6.1.1 프로젝트 이전의 상황
_________27.6.1.2 프로젝트 이후의 상황
_________27.6.1.3 일일 리그레션 테스트 실행
______27.6.2 고객이 발견한 결함의 효과
___27.7 정리
______27.7.1 배운 점
______27.7.2 계속되는 도전
_________27.7.2.1 모바일 장비
_________27.7.2.2 자동화 대 수동 테스트
______27.7.3 다음 계획

28장 탐색적 테스트 자동화: 시대를 앞서간 자동화의 예
___28.1 케이스 스터디의 배경
___28.2 트러블 매니저
___28.3 트러블 매니저 트랜잭션 테스트
______28.3.1 모든 필수 필드 값이 존재할 때 CreateTicket 트랜잭션 성공 테스트
______28.3.2 빠진 필수 필드 값이 있을 때 CreateTicket 트랜잭션 실패 테스트
___28.4 테스트 케이스를 프로그램으로 생성
___28.5 자동화 테스트를 고민하는 새로운 방식
___28.6 트러블 매니저 워크플로 테스트
___28.7 실행에 옮긴 테스트 생성
___28.8 마지막 단계
___28.9 출시 후
___28.10 정리
___ 28.11 감사의 말

29장 테스트 자동화의 일화
___ 29.1 쌀 세 톨
______29.1.1 테스트웨어의 리뷰
______29.1.2 누락된 유지보수
______29.1.3 대단히 성공적인 POC
___29.2 이해가 깊어져야 한다
___29.3 자동화 테스트 첫 날
______29.3.1 초기 투자
______29.3.2 자동화할 부분
______29.3.3 자동화 테스트 첫 날
_________29.3.3.1 비즈니스 레벨 키워드
______29.3.4 문제와 해결책
______ 29.3.5 자동화 방식 첫 번째 날의 결과
___29.4 자동화를 시작하기 위한 시도
___29.5 경영진과의 투쟁
______29.5.1 무조건 자동화하자는 관리자
______29.5.2 테스터는 프로그래머가 아니라는 관리자
______29.5.3 버그를 자동화하라는 관리자
______29.5.4 잘못된 방법으로 고객을 감동시키라는 관리자
___29.6 탐색적 테스트 자동화: 데이터베이스 레코드 잠김
______29.6.1 케이스 스터디
___29.7 임베디드 하드웨어와 소프트웨어 컴퓨터 환경의 테스트 자동화에서 얻은 교훈
______29.7.1 VV&T 프로세스와 툴
______29.7.2 교훈
______29.7.3 결과 요약
___29.8 전염되는 시계
______29.8.1 기존의 시계
______29.8.2 유용성 향상
______29.8.3 부득이한 추진
______ 29.8.4 배운 점
___ 29.9 자동화 시스템의 유연성
___29.10 너무 많은 툴과 부서간 지원 부족
______29.10.1 프로젝트 1: DSTL을 이용한 시뮬레이션
______29.10.2 프로젝트 2: TestComplete를 사용한 GUI 테스트
______29.10.3 프로젝트 3: Rational Robot
______29.10.4 프로젝트 4: 최후의 파이썬 프로젝트와 QTP용 POC
______29.10.5 프로젝트 5: QTP2
______29.10.6 이야기의 끝
___29.11 놀라운 결말로 끝난 성공
______29.11.1 선택한 툴
______29.11.2 툴 인프라스트럭처와 흥미로운 이슈
______29.11.3 시작
______29.11.4 예상하지 못한 일의 발생
___29.12 협력이 자원의 제약을 극복할 수 있다
___ 29.13 대규모 성공을 위한 자동화 프로세스
______29.13.1 시작점
______29.13.2 궁극적인 성공의 열쇠: 자동화 프로세스
______29.13.3 배운 점
______29.13.4 투자수익률
___ 29.14 테스트 자동화는 항상 보이는 것이 전부는 아니다.
______29.14.1 예외 처리만 한다고 좋은 테스트가 되지는 않는다
______29.14.2 때론 실패한 테스트가 믿을 만한 테스트다
______29.14.3 때론 마이크로 자동화가 잭팟을 터뜨린다

부록: 툴
찾아보기