간편결제, 신용카드 청구할인
삼성카드 6% (38,070원)
(삼성카드 6% 청구할인)
인터파크 롯데카드 5% (38,480원)
(최대할인 10만원 / 전월실적 40만원)
북피니언 롯데카드 30% (28,350원)
(최대할인 3만원 / 3만원 이상 결제)
NH쇼핑&인터파크카드 20% (32,400원)
(최대할인 4만원 / 2만원 이상 결제)
Close

소프트웨어 테스트 자동화 : 테스팅 전문가들의 생생한 사례연구 스토리로 익히는

원제 : Experiences of Test Automation: Case Studies of Software Test Automation
소득공제

2013년 9월 9일 이후 누적수치입니다.

판매지수 23
?
판매지수란?
사이트의 판매량에 기반하여 판매량 추이를 반영한 인터파크 도서에서의 독립적인 판매 지수입니다. 현재 가장 잘 팔리는 상품에 가중치를 두었기 때문에 실제 누적 판매량과는 다소 차이가 있을 수 있습니다. 판매량 외에도 다양한 가중치로 구성되어 최근의 이슈도서 확인시 유용할 수 있습니다. 해당 지수는 매일 갱신됩니다.
Close
공유하기
정가

45,000원

  • 40,500 (10%할인)

    2,250P (5%적립)

할인혜택
적립혜택
  • I-Point 적립은 출고완료 후 14일 이내 마이페이지에서 적립받기한 경우만 적립됩니다.
  • 추가혜택
    배송정보
    주문수량
    감소 증가
    • 이벤트/기획전

    • 연관도서(6)

    • 사은품(5)

    출판사 서평

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

    [이 책에서 다루는 내용 ]

    - 애자일 개발에서 테스트 자동화
    - 경영진의 지원이 성공적인 자동화를 이끌거나 무너뜨릴 수 있는 이유
    - 테스트웨어 아키텍처와 추상화 레벨 선택의 중요성
    - 자동화 효과 및 투자 대비 수익(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 때론 마이크로 자동화가 잭팟을 터뜨린다

    부록: 툴
    찾아보기

    본문중에서

    테스트 자동화 툴은 30여 년 동안 존재하여 왔지만, 많은 자동화 시도가 실패로 끝났다. 혹은 일부분만 성공했다. 왜 그럴까? 우리는 먼저 전작인 [소프트웨어 테스트 자동화(Software Test Automation)]에서 다뤘던 효과적인 자동화의 원칙들이 여전히 유효한 지를 확인하고 싶었고 그 외에도 실제 실무에 적용할 수 있는 다른 원칙들은 무엇이 있는지 알아보고 싶었다. 그래서 현실에서의 테스트 자동화 개발에 대한 정보를 모으기 시작했고, 발견한 사실이 즐거운 내용만은 아니었다. 지난 10년 동안 많은 사람들이 소프트웨어 테스트 자동화에서 성공을 거뒀고 그 중 많은 수가 우리 책을 참조했다. 물론 우리만이 좋은 자동화 지침을 발견해서 저술한 것은 아니었지만, 성공적이고 오래가는 자동화는 오늘날에도 여전히 찾기 힘든 듯하다. 이 책에 담긴 이야기들이 더욱 많은 이들의 테스트 자동화 업무를 돕기를 바란다.

    이 책은 현실적인 자동화 이야기들을 담고 있다. 테스트 자동화 기법은 이전 책이 출간된 1999년 이래로 괄목할 만한 성장을 해왔다. 우리는 성공적인 접근법이 무엇인지, 어떤 애플리케이션이 테스트 자동화를 통해 테스트되는지, 최근 몇 년간 테스트 자동화가 어떻게 변해왔는지를 알아내고자 했다. 사람들은 자동화의 문제점을 각각의 방식으로 해결한다. 우리는 그들의 경험에서 배울 점과 새로운 방식으로 테스트 자동화가 적용되는 시기와 방법을 찾고 싶었다.

    이 책에서의 케이스 스터디는 성공적인 접근 방식과 그렇지 않았던 방식 모두를 보여준다. 이 책은 보이지 않는 위험을 피하게 도와주고 이론이 아닌 실제 업무 환경에서 이뤄 낸 성공에서 배울 수 있는 지식을 제공한다. 또한 다양한 전문가들의 실제 경험을 독자들이 낱낱이 살펴볼 수 있도록 기획했다.

    이 책의 케이스 스터디는 주로 테스트 실행에 대한 자동화를 다룬다. 하지만 그 외의 자동화 유형이 언급된 장도 있다. 이 책에서는 시스템 레벨 자동화(사용자 인수 테스팅(user acceptance testing)을 포함한)가 중점적으로 다뤄지긴 하지만, 단위 테스팅(unit testing)이나 통합 테스팅(integration testing)을 다루는 장도 있다. 여러 유형의 애플리케이션과 환경 및 플랫폼에서의 테스트 자동화가 기술되며, 전형적인 개발 프로젝트와 애자일 개발 프로젝트에서의 상업용 애플리케이션과 오픈 소스 그리고 인하우스 툴을 다룬다. 부록에 기재된 것처럼 약 90여 개의 상업용과 오픈 소스 툴(테스팅 툴만 아니라 각 장의 저자들이 사용하는 모든 툴을 포함)이 있으며 우리는 수많은 다양한 툴에 감탄했다.

    이 책에 기술된 경험담이 모두 사실이기는 하지만 저자나 회사 이름을 기재하지 않은 경우도 있다. 우리는 케이스 스터디 저자들에게 일반적인 조언을 주는 것보다는 일어난 일을 모두 기술해 줄 것을 권장했다. 그러므로 이 책의 내용은 실제 일 그대로를 적은 것이다!
    (/ '저자 서문' 중에서)

    테스트 자동화는 QA와 테스트 엔지니어들의 로망인 것 같다. 테스트 자동화를 꾸며주는 화려한 수식어들을 듣고 있노라면, 당장이라도 나를 오아시스로 이끌어 줄 것만 같다. 자동화 버튼 한 번 눌러 두고, 그저 여유롭게 야자수 아래에서 열매나 따 먹으면 될 것 같은 상상을 하게 된다. 내 경험에 비추어보면, 국내에서는 5년 전만 해도, 테스트 자동화는 실패가 당연한 것으로 보였다. 자동화가 돌아간다는 짧은 환희만 맛볼 뿐, 인공호흡기를 늘 붙여 주어야 연명해나가는 것이 테스트 자동화였던 것 같다.

    교회를 다니지 않는 사람이라도 다윗과 골리앗의 이야기는 들어 본 적이 있을 것이다. 다윗은 왕의 갑옷을 입고 왕의 칼을 차고 시험 삼아 몇 걸음 걸어보지만, 거추장스러워서 도저히 행동 할 수가 없었다고 한다. 결국 그가 골리앗을 상대할 때 사용한 것은, 그의 손에 늘 있었던 물맷돌이었다. 골리앗과 같은 자동화에 맞서 승리를 약속해준다고 말하는 최신 툴과 플랫폼이 여기저기 많이 있지만, 오랜 시간에 걸쳐 사용하여 내 손에 익숙하지 않다면, 왕의 갑옷과 칼과 같게 되어 결국 몇 걸음 걷지 못하고 주저앉게 되는 듯하다. 이 책은 왕의 갑옷과 칼을 소개하는 책이 아니다. 이 책의 저자들은 스스로 오랜 시간 동안 손에 쥐고 수 없이 사용해 본 자신의 손에 맞는 물맷돌을 소개한다. 어떻게 성공했는지, 어떻게 실패했는지 솔직하게 말해준다. 여기 소개된 스토리들을 그대로 답습하는 것이 성공을 보장하진 않는다. 하지만 인내심을 갖고 내게 맞는 물맷돌을 찾아가는 여정에 있어 도움을 주는 것은 분명하다.

    시스템은 더욱 복잡해지고, 서비스를 제공해야 하는 환경은 점점 많아진다. 모바일 환경은 이제 확장 환경 중 하나가 아닌 필수가 되었다. 그렇다고 PC 환경도 놓칠 수는 없다. 이런 환경에서 테스트 커버리지는 개발자가 하든 테스트 엔지니어가 하든 상관없이, 혹은 맨 손으로 하건 자동화를 통해서 하건 상관없이 어느 수준 이상으로 달성해야 한다. 개발 환경에서 애자일 방법은 곧 반복적인 테스트를 말하고 이는 수동으로는 더 이상 감당할 수 없는 상황이다.

    이젠, 내 손에 익숙한 무엇인가를 들고 나가야 한다. 그것이 상용 툴일 수도 있고 오픈 소스 툴일 수도 있다. 이미지 기반의 툴이 될 수도 있고, DOM 트리 분석 기반 툴일 수도 있다. 무엇이 가장 좋은지는 누구도 장담할 수 없다. 다만 내 손에 익숙해져서 목표를 향해 던지고 싶을 때 던질 수 있는 물맷돌과 같은 툴이면 된다. 이 책의 사례를 통해, 내 손에 맞는 물맷돌을 찾고 던지는 연습을 시작해야겠다는 용기를 얻을 수 있을 것이다. 그리고 연습을 시작한다면 어느 순간에는 나도 이런 사례를 적게 될 것이다.
    (/ '옮긴이의 말' 중에서)

    저자소개

    도로시 그레이엄(Dorothy Graham) [저] 신작알림 SMS신청 작가DB보기
    생년월일 -
    출생지 -
    출간도서 0종
    판매수 0권

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

    마크 퓨스터(Mark Fewster) [저] 신작알림 SMS신청 작가DB보기
    생년월일 -
    출생지 -
    출간도서 0종
    판매수 0권

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

    생년월일 -
    출생지 -
    출간도서 0종
    판매수 0권

    현재 네이버 QA 랩에 재직 중이다. 테스트 자동화에 관심이 많고, 테스트 자동화를 활용한 효율적이면서 효과적인 테스트 방법을 항상 고민하고 있다. 에이콘출판사에서 펴낸 [소프트웨어 테스트 자동화](2013)를 공역했다.

    생년월일 -
    출생지 -
    출간도서 0종
    판매수 0권

    현재 네이버 비즈니스플랫폼 QA팀에서 QA 엔지니어로 재직 중이다. 저녁이 있는 아름다운 삶을 꿈꾸며, 효과적이고 효율적인 테스트를 위한 연구에 많은 관심을 갖고 테스트 자동화 관련하여 다양한 시도를 해보고 있다. 우리나라 QA 분야의 발전에 조금이나마 기여할 수 있는 방법을 여러모로 모색하는 중이다.

    생년월일 -
    출생지 -
    출간도서 0종
    판매수 0권

    현재 네이버 QA 랩에 재직 중이다. 주요 관심 분야는 테스트 자동화와 애자일 테스트다. 에이콘출판사에서 펴낸 [소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다](2009), [소프트웨어 테스트 자동화](2013)를 공역했다.

    생년월일 -
    출생지 -
    출간도서 0종
    판매수 0권

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

    이 상품의 시리즈

    이 책과 내용이 비슷한 책 ? 내용 유사도란? 이 도서가 가진 내용을 분석하여 기준 도서와 얼마나 많이 유사한 콘텐츠를 많이 가지고 있는가에 대한 비율입니다.

      리뷰

      0.0 (총 0건)

      구매 후 리뷰 작성 시, 북피니언 지수 최대 600점

      리뷰쓰기

      기대평

      작성시 유의사항

      평점
      0/200자
      등록하기

      기대평

      0.0

      교환/환불

      교환/환불 방법

      ‘마이페이지 > 취소/반품/교환/환불’ 에서 신청함, 1:1 문의 게시판 또는 고객센터(1577-2555) 이용 가능

      교환/환불 가능 기간

      고객변심은 출고완료 다음날부터 14일 까지만 교환/환불이 가능함

      교환/환불 비용

      고객변심 또는 구매착오의 경우에만 2,500원 택배비를 고객님이 부담함

      교환/환불 불가사유

      반품접수 없이 반송하거나, 우편으로 보낼 경우 상품 확인이 어려워 환불이 불가할 수 있음
      배송된 상품의 분실, 상품포장이 훼손된 경우, 비닐랩핑된 상품의 비닐 개봉시 교환/반품이 불가능함

      소비자 피해보상

      소비자 피해보상의 분쟁처리 등에 관한 사항은 소비자분쟁해결기준(공정거래위원회 고시)에 따라 비해 보상 받을 수 있음
      교환/반품/보증조건 및 품질보증 기준은 소비자기본법에 따른 소비자 분쟁 해결 기준에 따라 피해를 보상 받을 수 있음

      기타

      도매상 및 제작사 사정에 따라 품절/절판 등의 사유로 주문이 취소될 수 있음(이 경우 인터파크도서에서 고객님께 별도로 연락하여 고지함)

      배송안내

      • 인터파크 도서 상품은 택배로 배송되며, 출고완료 1~2일내 상품을 받아 보실 수 있습니다

      • 출고가능 시간이 서로 다른 상품을 함께 주문할 경우 출고가능 시간이 가장 긴 상품을 기준으로 배송됩니다.

      • 군부대, 교도소 등 특정기관은 우체국 택배만 배송가능하여, 인터파크 외 타업체 배송상품인 경우 발송되지 않을 수 있습니다.

      • 배송비

      도서(중고도서 포함) 구매

      2,000원 (1만원이상 구매 시 무료배송)

      음반/DVD/잡지/만화 구매

      2,000원 (2만원이상 구매 시 무료배송)

      도서와 음반/DVD/잡지/만화/
      중고직배송상품을 함께 구매

      2,000원 (1만원이상 구매 시 무료배송)

      업체직접배송상품 구매

      업체별 상이한 배송비 적용