로그인회원가입장바구니고객센터마이페이지회사소개
kangcom
전체
Home >   >   > 

소프트웨어 테스트 자동화

 [테스팅 전문가들의 생생한 사례연구 스토리로 익히는]
   
지은이 도로시 그레이엄, 마크 퓨스터   |   출판사 에이콘  |   발행일 2013년 12월 23일
 
클릭하시면 큰 도서이미지를 보실 수 있습니다.
판매가 45,000원40,500원 10%
마일리지 5% 2,250원
발행일 2013-12-23
ISBN 8960775029 | 9788960775022
기타정보 번역서 | 728쪽 | 일반
예상출고일 1~2일 이내 (근무일기준)
배송비 무료배송
   
소프트웨어
종합지수 12p 9 위
   
이 책의 원서
  Experiences of Test Automation: Case Studies of Software Test Automation
Addison-Wesley Professional | Dorothy Graham
 

테스트 자동화는 절대로 한 번에 끝나지 않는다. 그렇기에 계속해서 내 손에 익숙한 툴과 방법을 찾아 연습과 적용을 거듭하고, 인내하면서 가꿔 나가야 한다. 이 책에는 여러 분야에서 다양한 서비스와 제품을 맡은 테스트 엔지니어들의 자동화 스토리가 고스란히 담겨 있다. 무엇보다도, 효과적인 자동화 테스트의 본질을 설명하며 실제 자동화 프로젝트에서 얻은 가치 있는 경험과 팁, 교훈, 기억해야 할 점이 고스란히 담겨 있는 흥미진진하고 잘 작성된 광범위한 케이스 스터디 모음집이다.

★ 이 책에서 다루는 내용 ★
■ 애자일 개발에서 테스트 자동화
■ 경영진의 지원이 성공적인 자동화를 이끌거나 무너뜨릴 수 있는 이유
■ 테스트웨어 아키텍처와 추상화 레벨 선택의 중요성
■ 자동화 효과 및 투자 대비 수익(ROI) 계산 방법
■ 기술, 계획, 범위, 기대 결과를 포함하는 관리 관점의 이슈들
■ 모델 기반 테스팅(MBT) 자동화, 멍키 테스팅 자동화, 탐색적 테스트 자동화
■ 엔터프라이즈 급 자동화에서 표준, 커뮤니케이션, 문서, 유연성의 중요함
■ 지원 활동의 자동화
■ 자동화해야 할 테스트와 하지 말아야 할 테스트
■ 자동화의 숨겨진 비용들: 유지보수와 실패 분석
■ 테스트 자동화의 올바른 목적: 왜 ‘버그 찾기’가 좋은 목적이 될 수 없는가?
■ 교훈, 기억해야 할 내용, 도움이 될만한 팁

★ 이 책의 대상 독자 ★
테스트 자동화에 대해 고민하고, 구현하고, 사용하거나 관리하는 모든 사람들에게 매우 귀중한 책이 될 것이다. 테스터, 분석가, 개발자, 자동화 엔지니어, 자동화 아키텍트, 테스트 매니저, 프로젝트 매니저, QA 전문가, 기술 책임자 모두 이 책을 통해 얻을 수 있는 내용이 많을 것이다.

★ 이 책의 구성 ★
각 장의 사례는 개별적인 이야기이므로 순서대로 읽을 필요는 없다. 책의 순서는 단지 여러분에게 다양한 경험을 들려주기에 최적화된 순서로 되어 있을 뿐이다.

‘케이스 스터디 고찰’에서는 책에서 언급된 프로젝트 관리와 기술적인 이슈의 전반적인 관점과 요점을 설명한다. 또한 이슈에 대한 우리의 관점과 의견을 덧붙였다(테스트웨어 아키텍처 포함). 여기서는 저자들이 현재 진행하고 있거나 진행할 예정인 자동화 프로젝트에서 참고할 조언 중 핵심 부분을 요약해 이야기한다.

1장부터 28장은 케이스 스터디로 저자가 특정 상황에서의 잘된 점과 실패한 점, 얻은 교훈 등의 경험을 이야기한다. 이 중에는 파일 구조나 자동화 코드 같은 아주 구체적인 정보를 기술하는 장도 있고, 일반적인 장도 있다. 10장은 『Software Test Automation(소프트웨어 테스트 자동화)』 책에 실렸던 케이스 스터디를 보완한 것이고 나머지 장은 모두 새로운 내용이다.

‘29장, 테스트 자동화의 일화’는 여러 사람의 경험을 모아 놓은 책 속의 작은 책이라고 할 수 있다. 반 페이지부터 여러 페이지짜리도 있으며 유용하고 흥미로운 경험을 모아 놓았다.

마지막으로 부록에 실린 툴은 각 장에서 언급된 상업용과 오픈소스 툴을 소개한다.

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 때론 마이크로 자동화가 잭팟을 터뜨린다

부록: 툴
찾아보기

[ 저자 ]
도로시 그레이엄(Dorothy Graham)
전세계에서 유명한 컨설턴트이자 강사 및 저자로 약 40년간 소프트웨어 테스팅 분야에서 활약 중이다. 그로브 컨설턴트(Grove Consultants)에서 약 19년 동안 근무했고, 현재는 학술회와 저술에 힘쓰고 있다. 1993년과 2009년 유로스타 컨퍼런스에서 프로그램 위원장을 맡았고, 소프트웨어 테스팅 분야에서 유러피언 엑셀런스 어워드를 수상했다. 퓨스터와 함께 베스트셀러였던 『Software Test Automation(소프트웨어 테스트 자동화)』(Addison-Wesley, 1999)를 공저했다.

마크 퓨스터(Mark Fewster)
30년간 소프트웨어 테스팅과 자동화 분야에서 다양한 경험을 쌓았다. 다중 플랫폼 그래픽 애플리케이션의 개발자 및 관리자로서 견고한 테스트 자동화 아키텍처를 설계했다. 1993년 이후 지금까지 그로브 컨설턴트에서 소프트웨어 테스팅의 모든 분야에 관한 교육과 컨설팅에 힘쓰고 있다. 그레이엄과 함께 『Software Test Automation(소프트웨어 테스트 자동화)』(Addison-Wesley, 1999)를 공저했다.

[ 역자 ]
여용구
현재 네이버 비즈니스플랫폼 QA팀에 재직 중이다. 1년이 지나도 살아있는, 내실 있는 테스트 자동화에 관심이 있다. 주요 번역서로는 『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다』(에이콘출판, 2009)가 있다.

김윤명
현재 GlobalEnglish Korea Inc.에서 시니어 QA 엔지니어로 근무하고 있다. 관심사는 애자일 테스팅으로 애자일 테스팅의 올바른 프랙티스와 애자일 방법론 내에서의 효율적인 테스트 자동화를 고민하고 있다. 주요 번역서로는 『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다』(에이콘출판, 2009)와 『뷰티풀 테스팅』(지앤선, 2011)이 있다.

황영석
명지대학교에서 컴퓨터공학 석사학위를 받고, 네이버 비즈니스플랫폼 QA팀에서 품질 관리 업무를 하고 있다. 주요 관심 분야는 웹 테스팅, 모바일 테스팅, 자동화 테스팅이다.

성찬혁
현재 네이버 비즈니스플랫폼 QA팀에서 QA 엔지니어로 재직 중이다. 저녁이 있는 아름다운 삶을 꿈꾸며, 효과적이고 효율적인 테스트를 위한 연구에 많은 관심을 갖고 테스트 자동화 관련하여 다양한 시도를 해보고 있다. 우리나라 QA 분야의 발전에 조금이나마 기여할 수 있는 방법을 여러모로 모색하는 중이다.
등록된 서평이 없습니다.
 
전체평균(0)
회원평점   회원서평수 0
에이콘 출판사의 신간
『Go 언어를 활용한 마이크로서비스 개발: 매끄럽고 견고하면서도 효율적인 마이크로서비스 구현』
닉 잭슨 저
27,000원
(10%↓+5%)
 
『유니티 3D RPG 게임은 이렇게 만든다: RPG 게임 개발의 시작』
바헤 카라미언 저
27,000원
(10%↓+5%)
 
『텐서플로1.x로 배우는 머신 러닝 : 실용적인 사례로 만들어보는 머신 러닝 시스템』
콴 후아, 샴스 울 아짐, 사이프 아메드 저
27,000원
(10%↓+5%)
 
『금융공학으로 R 마스터하기 : R로 거래전략을 최적화하고 내 손으로 위기 관리 시스템 구축하기』
에디나 벨린게르, 페렌츠 일레, 밀란 바딕스, 아담 바나이, 게르게이 더로치, 바바라 도모토르, 게르게리 개블러, 대니엘 허브런, 페테르 주하즈, 이스트반 마르기타이, 발라츠 마커스, 피테르 메드베예프, 줄리아 몰나, 발라츠 아르패드 슈스, 아그네스 투짜, 타마스 바다스, 커터 바러디, 어그네시 비도비츠던치 저
27,000원
(10%↓+5%)
 
『손안의 자바: 초보자를 위한 자바 프로그래밍의 핵심 + 알파』
김지훈, 이현우 저
27,000원
(10%↓+5%)
 
이메일주소수집거부