Top

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

  • 원서명Experiences of Test Automation: Case Studies of Software Test Automation (ISBN 9780321754066)
  • 지은이도로시 그레이엄, 마크 퓨스터
  • 옮긴이여용구, 김윤명, 황영석, 성찬혁
  • ISBN : 9788960775022
  • 45,000원
  • 2013년 12월 23일 펴냄
  • 페이퍼백 | 728쪽 | 188*250mm
  • 시리즈 : 소프트웨어 테스팅

책 소개

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

이 책에서 다루는 내용

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

이 책의 대상 독자

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

이 책의 구성

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

다양한 장의 특성을 한눈에 볼 수 있게 요약해 읽을 부분을 쉽게 고를 수 있게 했다.

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

1장부터 28장은 케이스 스터디로 저자가 특정 상황에서의 잘된 점과 실패한 점, 얻은 교훈 등의 경험을 이야기한다. 이 중에는 파일 구조나 자동화 코드 같은 아주 구체적인 정보를 기술하는 장도 있고, 일반적인 장도 있다. 10장은 『Software Test Automation』에 실렸던 케이스 스터디를 보완한 것이고 나머지 장은 모두 새로운 내용이다. 29장, ‘테스트 자동화의 일화’는 여러 사람의 경험을 모아 놓은 책 속의 작은 책이라고 할 수 있다. 반 페이지부터 여러 페이지짜리도 있으며 유용하고 흥미로운 경험을 모아 놓았다.

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

이 책에 쏟아진 각계의 찬사

“여러분이 지금 손에 쥐고 있는 이 책에는 테스트 자동화에서 무엇이 효과적인지와 효과적이지 않은지, 힘들게 얻은 귀한 보물과도 같은 지식이 담겨 있다. 길을 잘못 들어섰을 때 참고할 수 있는 이정표를 보여주고 테스트 자동화를 성공으로 이끌어주어 막대한 시간과 비용을 절약할 수 있게 해주는 책이다.”
- 린다 헤이즈(Linda Hayes)

“도로시 그레이엄과 마크 퓨스터는 툴에서 방법론에 이르기까지 자동화에서 배운 눈을 뗄 수 없는 경험을 책으로 엮었다. 이 책은 매우 다양한 산업과 기술 분야의 프로젝트에서 경험한 내용을 정리한 케이스 스터디로서 여러분을 자동화 테스트의 세계로 깊이 빠져들게 만들 최초의 책이다. 유사한 부분과 반복되는 주제를 파악할 수 있고, 이를 통해 반드시 알아야 할 교훈과 피해야 할 함정을 알 수 있다. 테스트 자동화를 성공으로 이끄는 요인을 이해하고 영감을 얻고 싶으면 이 책을 처음부터 끝까지 읽어보기 바란다.”
- 앤드류 폴너(Andrew L. Pollner) / ALP 인터내셔널 사 회장 겸 CEO

“도로시 그레이엄과 마크 퓨스터는 베스트셀러인 『소프트웨어 테스트 자동화(Software Test Automation)』(Addison-Wesley, 1999) 출간 이후 꾸준히 테스트 자동화를 해왔다. 애자일 방법론 덕분에 테스트 자동화는 최근 테스트 사례에서 가장 중요한 주제가 됐다. 이 책의 테스트 케이스들은 폭넓은 관점에서 잘 정리되어 있어 매우 실용적이고 훌륭하다. 테스트 자동화를 진행하고 있거나 시작하려는 모든 이에게 이 책을 강력히 추천한다.”
- 에릭 판 비넨달(Erik van Veenendaal) / Improve Quality Services의 창립자이자 TMMi 재단의 부의장

“이 책을 펼치면 여러분의 눈 앞에서 테스팅 컨퍼런스가 개최되며 풍부한 케이스 스터디와 통찰력으로 구성된 세션을 관람할 수 있다. 물론 컨퍼런스 참가비용보다 훨씬 저렴하며 직접 컨퍼런스에 참석할 필요도 없다. 특히 ‘케이스 스터디 고찰’에 모든 내용이 간결하게 정리되어 있어서 이 부분을 참고하면 자동화를 성공시키기 위해 생각할 수 있는 다양한 관점을 효율적으로 찾아볼 수 있다. 이러한 내용은 컨퍼런스에서도 쉽게 들을 수 없다.”
- 한스 부왈다(Hans Buwalda)

“실제 자동화 프로젝트에서 얻은 가치 있는 경험과 팁, 교훈, 기억해야 할 점이 고스란히 담겨 있는 흥미진진하고 잘 작성된 광범위한 케이스 스터디 모음집이다. 자동화의 여정에서 어떤 것이 효과적이고 어떤 것이 그렇지 않은지를 자신의 직장 상사나 동료에게 알려주고 싶은 사람에게 아주 유용할 것이다.”
- 이사벨 에반스(Isabel Evans) / FBCS CITP, 돌핀 컴퓨터 액세스(Dolphin Computer Access)의 품질 관리자

“이 책에서는 무엇보다 먼저 효과적인 자동화 테스트의 본질을 설명한다. 매우 다양한 상황에서 오랜 기간 겪으면서 얻은 가치 있는 경험을 볼 수 있다. 자동화 테스트를 사용할 때 이 책을 참고하면 조직과 프로젝트에 가장 적합한 방법을 찾을 수 있을 것이고 문제 해결에도 도움이 될 것이다. 관리자, 테스터, 자동화 엔지니어 등 테스트에 관여하는 모두에게 대단히 가치가 높은 책이다.”
- 마틴 긱센(Martin Gijsen) / 독립 테스트 자동화 아키텍트

“도로시 그레이엄과 마크 퓨스터가 집필한 이 책은 테스트 자동화의 이론과 현실 사이에 매우 중요한 다리를 놓았다. 테스트 자동화 프레임워크의 설계와 구현은 선행 경험을 통해서만 얻을 수 있는 재사용 가능한 표준에 매달리는 정밀하지 못한 과학이다. 이 책은 선행 경험을 쌓는 데 도움이 된다. 사법 체계에서 앞선 판례가 이후의 법적 판결을 지지하는 데 인용되듯이, 이 책의 다양한 케이스 스터디도 소프트웨어 테스트 자동화 프레임워크를 설계하고 구현할 때나 지원하고 교육할 때 예시 자료로 활용될 수 있다.”
- 디온 존슨(Dion Johnson) / 자동화 테스트 연구소(Automated Testing Institute) 소프트웨어 테스트 컨설턴트이자 원리 고문

“오랫동안 ‘테스트 자동화는 해봐야 소용없다’는 입장을 유지해왔지만, 이 책은 이런 내 입장을 잠시 멈추고 심사숙고하게 만들었다. 또한 열린 마음으로 ‘아, 그건 미처 생각하지 못했네’라는 느낌을 갖게 했다. 테스트 자동화를 도입하려는 모든 조직에게 첫 레퍼런스로 이 책을 추천한다.”
- 오드리 렝(Audrey Leng)

“이 책은 놀라운 성과다. 테스트 자동화 분야에서 지금까지 쓰여진 최고의 책 중 하나라고 믿는다. 도로시와 마크는 눈길을 끄는 팁과 기억할 점, 배운 점을 포함한 완전히 새로운 개념의 접근 방법으로 28개의 케이스 스터디를 제시한다. 일상적인 경험과 성공, 실패에서 나오는 이 케이스 스터디는 자동화의 여러 관점과 다양한 환경, 혼합된 솔루션을 포함한다. 책은 지혜의 근원이며, 기억을 자극하여 배우는 데 도움을 주는 스토리텔링을 사용하기에 좋은 방법이다. 어떤 수준의 테스트 자동화든 현재 참여하고 있거나 참여할 계획이 있는 사람이라면 반드시 이 책을 봐야 한다.”
- 미케 게베스(Mieke Gevers)

추천의 글

테스트 자동화는 성배이고 젊음의 원천이며 현자의 돌이다. 테스터는 수십 년 동안 수동 테스트(테스트 케이스와 테스트 데이터 생성, 시스템 환경 설정, 테스트 실행, 기대 결과와 실제 결과 비교, 결함 보고)를 할 때의 힘들고 단조로운 작업을 반복하는 것을 해결할 방안으로 테스트 자동화를 생각해왔다. 테스트 자동화는 이 모든 작업을 단순화해줄 수 있다.

그렇지만 불행히도 성공적이고 효과적이며 비용 효율이 높은 테스트 자동화는 달성하기 어렵다. 대부분 테스트 자동화는 이미 방향을 잃은 후에 시작하거나, 계속 실패를 반복하는 프로젝트에 적용하는 경우가 많다.

자동화가 실패하는 이유는 여러 가지이지만, 대체로 실현 불가능한 기대치로 인한 경우가 많다. 이외에도 시간이나 사람, 돈 등 불충분한 자원 할당이나 요구사항에 맞지 않는 툴, 성공하려는 성급한 마음에 품질이 저하되거나 테스트 자동화도 개발 업무와 동일한 전문적 접근이 필요하다는 사실을 충분히 이해하지 못해서 실패한다.

도로시와 마크가 1999년에 펴낸 첫 책 『Software Test Automation』은 이러한 주제를 다루는 표준이 되었다. 이 책의 앞 부분에서는 대부분의 성공적인 자동화 업무(스크립트 기법, 비교 업무 자동화, 테스트웨어 아키텍처, 유용한 메트릭 등)에서 볼 수 있는 사례를 상세히 기술했다. 이어서, 테스트 자동화 업무를 개발했던 여러 조직의 경험담을 기술했다. 이제 두 저자들은 10여년 동안 쌓은 지식을 바탕으로 조직적이며 경험을 공유하는 자동화 업무와 관련한 새로운 가이드를 제시한다. 이 책은 테스트 자동화의 가장 현대적이면서도 고전적인 접근 방식을 기술하면서 최신의 정보까지 모두 제공한다. 각 장에서는 독특한 자동화 업무 관련 이야기(성공담과 실패담)를 펼친다.

이외에도 합리적이고 실현 가능한 목적, 경영진의 지원, ROI를 비롯한 메트릭, 필요한 기술, 계획, 기대치 설정, 관계 형성, 툴, 교육, 정치 등 성공적인 테스트 자동화에 필요한 모든 사항을 반복해 이야기한다. 이 같은 주제는 프로젝트에서 적용 가능하며 개인에게도 동일하게 적용할 수 있다. 이 책의 좋은 점은 테스트 자동화의 영역에서 한 발짝 벗어나 더 폭넓은 정황에서 이러한 주제를 고려해볼 수 있게 한다는 점이다. 내가 도로시와 마크를 처음 만난 건 1998년 뮌헨에서 열린 유로스(EUROSTAR) 컨퍼런스였다. 당시 이들의 테스트 자동화 관련 지식과 같은 업무를 하는 다른 사람을 돕겠다는 열정에 감명을 받았다. 도로시와 마크의 뛰어난 업적을 축하하며 이 책을 추천한다.

- 리 코플랜드(Lee Copeland)

저자/역자 소개

저자 서문

테스트 자동화 툴은 30여년 동안 존재했지만, 많은 자동화 시도가 실패로 끝나거나 일부분만 성공했다. 왜 그럴까? 우리는 먼저 전작인 『Software Test Automation』에서 다뤘던 효과적인 자동화의 원칙이 여전히 유효한지를 확인하고 싶었고, 이외에도 실무에 적용할 수 있는 그 밖의 원칙은 무엇이 있는지 알아보고 싶었다. 그래서 실제 테스트 자동화 개발 관련 정보를 모으기 시작했고, 꽤 기쁜 사실을 발견했다. 10년간 많은 사람이 소프트웨어 테스트 자동화를 성공했고 많은 수가 우리 책을 참조했다. 물론 우리만 좋은 자동화 사례를 발견해서 저술한 것은 아니었지만, 성공적이고 오래가는 자동화는 오늘날에도 여전히 찾기 힘든 듯하다. 이 책에 담긴 이야기가 더욱 많은 이들이 테스트 자동화 업무를 하는 데 도움이 되기를 바란다.

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

이 책의 케이스 스터디는 성공적인 접근 방식과 실패한 방식 모두를 보여준다. 이 책은 보이지 않는 위험을 피하게 도와주고 이론이 아닌 실제 업무 환경에서 이룬 성공에서 배운 점을 이야기한다. 또한 다양한 전문가의 실제 경험을 살펴볼 수 있는 좋은 기회이다. 케이스 스터디에서는 주로 테스트 실행 자동화를 다루지만 자동화 유형이 언급된 장도 있다. 또한 사용자 인수 테스팅(user acceptance testing)을 포함한 시스템 레벨 자동화가 중점적으로 다뤄지며, 단위 테스팅(unit testing)이나 통합 테스팅(integration testing)을 다루는 장도 있다. 여러 유형의 애플리케이션 이외에 다양한 환경과 플랫폼에서의 테스트 자동화가 기술되며, 전형적인 개발 프로젝트와 애자일 개발 프로젝트에서의 상업용 애플리케이션과 오픈소스, 인하우스 툴을 다룬다. 부록에 기재된 것처럼 90여 개의 상업용과 오픈소스 툴(테스팅 툴만 아니라 각 장에서 사용하는 모든 툴을 포함)이 있으며 수많은 다양한 툴이 있다는 사실에 감탄했다.

경험담을 이야기할 때 저자나 회사 이름을 기재하지 않거나 별칭으로 한 경우도 있지만 내용은 모두 사실에 기반했다. 케이스 스터디를 이야기할 때 일반적인 조언을 주는 것보다는 일어난 일을 모두 기술해 줄 것을 권장했기 때문에 책에서 이야기하는 내용은 실제 있었던 일 그대로다!

저자 소개

도로시 그레이엄(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와 테스트 엔지니어의 로망이다. 테스트 자동화를 꾸며주는 화려한 수식어를 듣고 있으면, 당장이라도 나를 오아시스로 이끌어 줄 것만 같다. 자동화 버튼을 한 번 눌러 두고, 그저 여유롭게 야자수 아래에서 열매나 따 먹으면 될 것 같은 상상을 하게 된다. 하지만 현실은 다르다.

내 경험에 비추어보면 국내에서는 5년 전만 해도, 테스트 자동화는 실패가 당연한 것으로 보였다. 자동화가 돌아간다는 짧은 환희만 맛볼 뿐, 인공호흡기를 늘 해주어야 연명해나가는 것이 테스트 자동화였던 것 같다.

다윗과 골리앗의 이야기를 들어 본 적 있을 것이다. 다윗은 왕의 갑옷과 칼을 착용하고 시험삼아 몇 걸음 걸어보지만, 거추장스러워서 도저히 행동할 수 없었다고 한다. 결국 다윗이 골리앗을 상대할 때 사용한 것은, 늘 손에 있던 물맷돌이었다. 골리앗과 같은 자동화에 맞서 승리를 약속해준다고 말하는 최신의 툴과 플랫폼이 많이 있지만, 오랜 시간에 걸쳐 사용하여 내 손에 익숙하지 않다면 왕의 갑옷과 칼처럼 결국 몇 걸음 걷지 못하고 주저앉게 될 것이다.

이 책은 왕의 갑옷과 칼을 소개하는 책이 아니다. 이 책의 저자들은 스스로 오랜 시간 동안 손에 쥐고 수 없이 사용해 본 자신의 손에 맞는 물맷돌을 소개한다. 어떻게 성공했는지, 어떻게 실패했는지 솔직하게 말해준다. 여기 소개된 스토리들을 그대로 답습하는 것이 성공을 보장하진 않는다. 하지만 인내심을 갖고 내게 맞는 물맷돌을 찾아가는 여정에 있어 도움을 주는 것은 분명하다.

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

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

옮긴이 소개

여용구

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

김윤명

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

황영석

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

성찬혁

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

목차

목차
  • 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 때론 마이크로 자동화가 잭팟을 터뜨린다
  • 부록: 툴
  • 도서 오류 신고

    도서 오류 신고

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

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

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