마이크로소프트 테스팅의 실체를 속속들이 들여다 본다! 마이크로소프트의 유명 현직 테스팅 전문가(SDET)들이 집필한 소프트웨어 테스팅 실무서. 사내 9,000여 명의 테스터가 사용하고 있는 툴과 시스템, 베스트 프랙티스를 소개한다. 마이크로소프트의 테스트 설계와 관리 방식, 그들만의 교육 방법과 커리어 개발 방식, 앞으로의 도전을 알려준다.


[ 소개 ]

놀랍도록 멋진 책이다. 소프트웨어 테스팅에 관련된 모든 사람이 반드시 읽어야 할 서적이다. 마이크로소프트의 소프트웨어 테스팅에 대한 접근 방법과 미래의 테스팅에 대한 시각을 엿볼 수 있다.

흥미로운 조합: 세상에서 가장 어려운 테스팅 문제를 접하는 회사에서 훌륭한 테스터들이 들려주는 테스팅 이야기

마이크로소프트는 테스팅과 테스터에 대단한 가치를 두는 기업이다. 그들의 성공과 도전을 공유하는 경험담은 모든 테스팅 조직에 훌륭한 교훈이다.


마이크로소프트 테스팅의 실체를 들여다 본다!

마이크로소프트가 개발자 수만큼의 테스터를 두고 있다는 사실은 놀랄 만한 일이다. 150개가 넘는 제품 포트폴리오의 품질을 관리하는 테스팅 부문의 강조 또한 놀랍다.

마이크로소프트에서도 유명한 3명의 현직 테스팅 전문가가 집필한 이 책은 사내 9,000여 명의 테스터가 사용하고 있는 툴과 시스템, 모범 사례를 소개한다. 마이크로소프트의 테스트 설계와 관리 방식, 그들만의 교육 방법과 커리어 개발 방식, 앞으로의 도전에 대해 배워보자. 조직에 맞게 적용할 수 있는 실용적 통찰력을 얻을 수 있다.


[ 이 책에서 다루는 내용 ]

▶ 제품 생명주기에 걸쳐 효과적인 테스트를 설계하고 실행하는 방법
▶ 기능 테스트의 비용과 리스크를 최소화하고 구조적 기법의 적용 시점을 파악하는 방법
▶ 버그와 잠재적인 유지 보수 이슈를 파악하기 위해 코드 복잡도를 측정하는 방법
▶ 모델을 사용해 테스트 케이스를 생성하고 예측 불가능한 애플리케이션 동작을 찾고 리스크를 관리하는 방법
▶ 자동화 테스트를 적용하는 시점을 파악하는 방법과 자동화 테스트의 장기적 사용을 위해 설계하고 이를 자동화 인프라스트럭처에 통합하는 방법
▶ 우수한 테스터의 특징을 파악하고, 테스트 실행, 시스템 검사, 효율적인 진척도를 추적하는 데 효과적인 툴을 검토하는 방법
▶ 서비스와 상용 패키지 소프트웨어 테스팅의 차이점을 탐색하는 방법


[ 이 책의 대상 독자 ]

마이크로소프트의 테스터에 관심 있거나 마이크로소프트에서 테스트에 어떻게 접근하는지 알고 싶은 사람을 위한 책이다. 소프트웨어 테스팅을 다룬 많은 책을 대체할 수는 없지만 마이크로소프트가 소프트웨어를 개선하기 위해 테스팅 기법과 방법론을 어떻게 적용하는지는 알 수 있을 것이다.

마이크로소프트 테스터에겐 자신이 몸담은 회사에서 사용 중인 기법과 접근 방법을 담고 있으므로 관심이 있을 것이다. 테스터가 아닌 분들도 마이크로소프트에서 테스터의 역할을 알게 돼 흥미로울 것이다.


[ 이 책의 구성 ]

이 책은 독자가 마이크로소프트 제품, 마이크로소프트 엔지니어, 마이크로소프트 테스터, 테스트 역할, 엔지니어링 소프트웨어에 대한 일반적인 접근 방법에 익숙해지게 하는 것으로 시작한다. 2부에서는 마이크로소프트에서 일반적으로 사용하는 테스트 접근 방법과 툴을 다룬다. 3부에서는 테스팅에 사용하는 툴과 시스템을 소개한다. 마지막 4부에서는 마이크로소프트의 테스팅과 품질에 대한 미래의 방향과 미래를 만들기 위한 방법을 설명한다.


[ 추천의 글 ]

올해 초 나의 멘토이자 절친한 친구이며 나와 같은 윈도우 인터내셔널 팀원인 팀과 나는 우리의 기술 역량을 높이는 방법에 대해 토론 중이었다. 그때 팀이 아주 좋은 책을 읽고 있다며 내게 이 책의 원서 󰡔『How we test Software at Microsoft』를 내밀었다. 이 책에서 저자들은 단순한 테스팅 이론을 다룬 기존 테스팅 책들과 달리 자신들의 수많은 경험과 시행착오를 통해 체득된 내용을 다룬다. 실제로 마이크로소프트의 테스트 리더들은 실무자 관리와 테스트의 진행 상황 보고 업무는 물론 축적된 경험과 기술을 바탕으로 상당한 전문성을 확보하고 있다. 그리고 구체적으로 더 나은 테스트를 하기 위해 개선해야 할 점뿐만 아니라 실무자들에게 구체적으로 도움을 줄 수 있는 부분이 무엇인지 치열하게 고민한다. 따라서 유능한 리더들인 저자진의 생생한 경험이 녹아있는 이 책은 마이크로소프트 내의 테스터들에게도 널리 추천되고 있다.

최근 국내 회사들 또한 테스트에 대한 인식이 높아지고 있으며 상당히 실력 있는 테스터들을 보유하고 있다. 다만 한 조직이 소프트웨어의 품질과 테스팅을 내재화하는 과정은 많은 시간이 걸리며 수많은 시행착오와 끊임없는 개선작업을 요구한다. 다만 다양한 소프트웨어 제품을 출시하는 마이크로소프트는 남들보다 앞서 이런 과정을 거침으로써 역량 있는 내부 인력과 최적의 프로세스와 다양한 툴들을 보유하게 됐다.

이 책에서 독자들은 구체적으로 어떻게 소프트웨어 테스트가 한 조직에 녹아 들고 어떤 방식으로 활용되면서 내재화되는지에 대한 노하우를 익히게 된다. 소프트웨어 테스팅에는 정답도 은총알도 없다. 조직과 제품 성격에 맞는 소프트웨어 테스팅과 품질문화가 정착되기까지는 우리 테스터들의 열정과 노력 그리고 조직의 지원이 절실하다. 이 책에서 밝혀지는 여러 가지 방법과 노하우가 독자들이 속한 조직에 맞게 응용되고 실천되어 여러분의 테스팅에 일조하기를 기원하며 이 책을 국내 독자들에게 추천한다.

[ 한국어판 특별 서문 ]

여러분이 한국어로 번역된 『How We Test Software at Microsoft』에 있는 이 글을 읽고 있다니 무척 놀랍습니다. 서울은 이미 세계적인 기술 중심지이고, 한국에서 소프트웨어와 기술의 발전은 계속해서 빠르게 진행될 것이라 생각합니다.

저의 첫 번째 업무는 한국어, 중국어, 일본어 버전 윈도우 95의 네트워크 컴포넌트 테스팅이었습니다(Bj와 저는 같은 장소에서 일했습니다). 한국 출신의 훌륭한 테스터와의 협업은 매우 즐거운 일이었고, 우리 작업이 한국어로 번역돼 출시되는 것은 경이로운 일이었습니다.

우리의 50년 테스팅 경험을 한국 독자와 공유할 수 있게 돼 무척 기쁩니다. 이 책에서 소개한 기법, 접근 방법, 사례는 마이크로소프트의 소프트웨어 테스팅 실무 중 일부입니다. 책을 통해 한국의 모든 독자가 실무에서 활용할 수 있는 조그만 아이디어를 발견할 수 있기 바랍니다. 한국에서 소프트웨어의 중요성이 커지고 있으므로, 독자 여러분 모두가 이 책에서 미래의 소프트웨어를 다듬고 개선할 수 있는 무언가를 발견하길 바랍니다.



이 프로젝트를 처음 시작했을 때는 책이 집필돼 출판되기만을 바랬습니다. 그런데 한국어로도 번역된다니 영광입니다. 전 세계적으로 소프트웨어는 중요한 위치를 차지하고 있으며, 테스팅은 이런 세계 소프트웨어 산업 생태계의 핵심에 위치한다고 생각합니다.



저는 1994년에 윈도우 95 국제화 테스트 팀에 소프트웨어 테스트 엔지니어로 합류하기 위해 일본에서 시애틀로 전근했습니다. 우리의 목표는 영어판 윈도우와 동아시아판 윈도우 버전 간의 격차를 줄이는 것이었고, 한국, 일본, 중국의 팀들과 즐겁게 일했습니다. 그 당시, 테스팅의 초점은 가능한 한 많은 버그를 발견하는 데 있었고, 많은 개발자가 2바이트 인코딩을 이해하지 못했기 때문에 파싱 에러와 같은 버그 리포팅은 어려운 일이 아니었습니다. 하지만 기술은 변하고, 개발자도 문제점들을 예방하는 방법을 알고 적용하게 돼 우리는 테스팅 접근 방법을 수정해야 했습니다. 저는 소프트웨어 테스팅 관련 책을 읽기 시작했습니다. 버그를 찾는 테스팅 프로세스를 이해했지만 소프트웨어 테스팅의 기술적 원리는 이해하지 못하고 있었고, 이런 원리를 업무에 적용해 문제를 예방하는 데까지는 이르지 못했습니다.

현재 저는 테스트 아키텍트로서 마이크로소프트에서 새로운 테스터에게 수많은 제품을 테스트하는 데 사용되는 기술적 원리와 그 원리를 실무에 적용하는 법을 가르치고 있습니다. 기술적인 원리가 실무에 적용되어 제품의 품질을 향상시키고, 제품에 포함될 수 있는 문제를 예방하며, 전체 비용을 절감시킵니다. 이와 같이 테스팅의 기술적인 원리와 이를 실무에 적용하는 방법을 가르치고 있지만 저도 계속해서 테스팅을 공부하는 중입니다. 제품의 품질을 향상시키기 위해서는 끊임없이 배워야 한다고 생각합니다. 고객들이 소프트웨어를 접하는 방법은 급격하게 변화하고 있으므로 테스팅 접근 방법을 계속 배워 적용해야 합니다. 이 책은 테스팅 관련 모든 해결책을 알려주지는 않습니다. 그러나 앨런과 켄, 그리고 제가 수년간 다양한 제품을 테스팅하면서 배웠던 경험을 담고 있습니다. 이 책은 어떤 독자에게는 새로운 지식을 제공하고, 이미 주제를 알고 있는 독자에게는 새로운 시각을 제시합니다. 우리의 책이 한국어로 번역돼 기쁘고, 한국의 테스팅 입문자나 소프트웨어 테스팅 경력자가 이 책을 통해 소프트웨어 테스터 역할 수행에 도움이 될 수 있는 지식을 많이 얻었으면 합니다.



[ 저자 서문 ]

2007년 늦가을 아침, 관리자 켄 존스톤이 내게 “꼭 책을 한 권 써보세요”라고 말을 건넸다.

그는 테스트 컨퍼런스에서 발표를 마치고 돌아왔는데, 청중의 반응에 몹시 흥분한 상태였다(당시 제목이 『How we test software at Microsoft』는 아니었다). 켄은 발표를 좋아했지만 책의 저자는 나여야 한다고 생각한 것 같다.

나는 농담으로 “좋죠, 안 될 거 뭐 있나요?”라고 말했다. 책은 마이크로소프트에서 사용하는 일반적인 테스트 접근 방법에 대한 피상적 지식과 소프트웨어 테스팅 과정 교육 내용을 담을 수 있을 것이라고 말했다. 흥미는 있었지만 테스팅을 다룬 책은 이미 수도 없이 많았고, 내가 읽은 것도 수십 권에 달하며, 매우 훌륭한 책도 몇 권 있었다. 지금 이 시점에서 테스팅 책을 또 낸다면 테스팅 커뮤니티에 어떤 가치가 있을까?

켄에게 무의미함을 얘기하려고 할 때 중요한 점을 깨달았다. 마이크로소프트에는 세계 최고의 소프트웨어 테스트 교육 과정이 있다. 교육 과정의 교재와 구성은 좋지만 그게 전부는 아니다. 학생들에게 인상을 남기고 영향을 주는 건 과정 전반에서 소개되는 강사의 일화, 성공 사례, 소소한 얘기라고 생각했다. 마이크로소프트가 테스트 접근 방법을 어떻게 사용하는지에 대한 정보와 사례를 담으면 책이 더욱 재미있어질 거라고 생각했다. 교육 과정에서 가르쳤던 내용을 뛰어넘어 테스터에게 재미있을 테스트 개념과 사례를 생각하기 시작했다. 내가 좋아하는 프로그래밍 책은 기술적인 내용은 물론 다양한 사례로 가득 차 있음을 깨달았다.

곧바로 나는 기획안을 쓰기 시작했다. 윤곽이 드러나기 시작했고, 4가지 주제를 갖춘 책의 형태가 만들어졌다. 1부는 마이크로소프트의 사람과 엔지니어링에 대해 일반적인 접근 방법을 사용해 합리적으로 서술했다. 2부와 3부는 마이크로소프트에서 테스팅하는 방법과 사용 툴에 초점을 맞췄고, 4부는 마이크로소프트 내부의 테스팅 미래를 기술했다. 마이크로소프트 출판사에 저서 기획안을 보낸 나는 책의 가능성에 흥분한 상태였지만 한편으론 출판사가 내 제안을 거절하면 그냥 포기하려는 생각도 했다. 다행히 우려한 일은 일어나지 않았고, 얼마 후 나는 컴퓨터 앞에 앉아 첫 문장을 어떻게 시작할까 고민하고 있었다.

시작할 때부터 켄이 처음 2개 장을 써주기를 바랬다. 켄은 마이크로소프트의 관리자로 수년 동안 일했으며, 인사 관련 부문의 전문가였다. 제안서를 제출할 때 켄은 우리 그룹에서 오피스 온라인 그룹 관리자로 자리를 옮겼다. 얼마 지나지 않아 켄은 소프트웨어 플러스 서비스를 어떻게 테스트하는지에 대한 장도 써야 했다. 켄은 웹서비스를 어떻게 테스트하는지 정의하는 회사의 리더가 됐으므로 직접 14장 ‘소프트웨어 플러스 서비스 테스팅’을 꼭 집필해야 했다. 나중에 마이크로소프트에서 가장 유명한 테스터인 비제이 롤리슨에게 기능적, 구조적 테스트 기법 부분을 써달라고 부탁했다. 비제이 롤리슨은 핵심 소프트웨어 테스팅 과정을 설계했고, 그 누구보다도 테스팅 분야를 잘 알고 있으며, 나보다 테스팅 관련 서적을 많이 읽은 유일한 사람이다. 켄과 비제이, 나 이렇게 세 명으로 구성한 저자진은 꽤 괜찮은 편이었다. 우리가 작업한 결과물은 저마다 달랐고, 마무리 시점에는 마이크로소프트 테스터의 다양함을 반영하는 자료와 저작 스타일을 혼합해야 했다. 비제이는 교수이고, 켄은 역사학자나 이야기꾼이 되려 하고, 나는 정보를 모아서 사실만을 기술한다고 농담을 하곤 했다. 몇 장을 쓰고 나서 우리는 서로의 작업을 편집하고 조언을 했고, 그 결과 책 전체가 하나의 스타일로 모아졌다.

책을 써야 한다는 숙제가 앞에 놓여있을 때 삶의 모든 작은 방해물은 점점 커진다. 이 책을 시작하고 나서 켄은 이전 직무인 마이크로소프트 테스트 엑셀런스 팀의 감독직을 맡게 됐다. 책을 쓰기 시작해서 새로운 직무에 도전했는지는 나도 모르겠다. 그렇지만 그의 도전으로 이 책에 많은 도움이 된 마이크로소프트의 테스트 리더십을 좀 더 깊이 알게 됐다.

이 책을 쓰면서 가장 염려스러웠던 점은 마이크로소프트 테스팅의 많은 부분을 모두 다루지는 못했다는 점이다. 마이크로소프트에는 9,000명 이상의 테스터가 있다. 이 책에서 다룬 테스트 접근 방법은 마이크로소프트의 테스터가 가장 많이 사용하는 방법이지만 미처 다루지 않은 다른 훌륭한 방법도 마이크로소프트에는 무척 많다. 그 중에는 이 책에서 다룬 주제를 변형한 방법도 있다. 우리가 가장 중요하다고 생각하는 테스팅에 관련해 가능한 한 많은 개념을 기술하려고 노력했다. 사실 이 책의 제목이 약간 두렵긴 하다. 『소프트웨어 테스팅, 마이크로소프트에선 이렇게 한다』는 마이크로소프트의 모든 테스터가 작업하는 내용을 이 책에 담았음을 의미하지만 사실 그렇지는 않다. 테스터도 무척 많고, 포트폴리오도 많으므로 마이크로소프트의 모든 테스터가 하는 테스팅을 기술할 수는 없다. 그래서 우리는 절충안을 찾았다. 이 책은 마이크로소프트 테스터가 가장 일반적으로 사용하는 테스팅 작업, 툴, 기법 등을 기술한다. 모든 팀이 책에 나오는 모든 작업을 하지는 않지만 대부분은 이렇게 작업한다. 이 책에 쓰기 위해 고른 내용은 모두 마이크로소프트 제품 테스팅에 성공적으로 적용된 것이고, 이 책의 주제는 우리가 알고 있는 작업의 일부분이다.

마지막으로 책 집필은 끝냈지만 테스터로서 더 잘할 수 있다는 것을 알고 있다. 아직 부족하지만 출판 시점이 다가왔고, 우리는 고객 지원도 열심히 할 계획이다. 책 내용 중 무엇이든 저자와 토론하고 싶다면 웹사이트(www.hwtsam.com)를 방문하라. 집필진은 독자의 의견을 듣고 싶다.



[ 저자 소개 ]

앨런 페이지 (Alan Page)
1993년 소프트웨어 테스팅 분야 일을 시작해 1995년 마이크로소프트에 입사했다. 마이크로소프트에서 윈도우, 인터넷 익스플로러, 윈도우 CE 분야 등에서 다양한 작업을 했다. 윈도우 CE팀에 재직할 때 2001년 마이크로소프트의 첫 번째 테스트 아키텍트가 됐다. 2005년 엔지니어링 우수 팀의 구성원이 됐고, 현재 마이크로소프트의 테스터에게 교육과 컨설팅을 하는 테스트 우수 팀의 관리자다.

켄 존스톤 (Ken Johnston)
마이크로소프트 오피스 인터넷 플랫폼과 운영 팀의 그룹 관리자다. 이 팀은 오피스 온라인, 오피스 라이브, CRM 온라인 등과 같은 서버 제품과 서비스를 위한 관리 기능을 개발한다. 1998년 입사 이후 사이트 서버와 MCIS의 테스트 리더, 익스체인지, 지식 노동자 서비스, Net Docs, 마이크로소프트 과금 및 가입자 플랫폼 서비스 등의 테스트 관리자로 일했다. 2004년부터 2006년까지는 마이크로소프트 테스트 우수 팀의 관리자로 근무했다.

비제이 롤리슨 (Bj Rollison)
엔지니어링 우수 팀의 테스트 아키텍트다. 1994년 마이크로소프트에 입사해 윈도우 95 팀에서 근무를 시작했다. 1999년 테스트 관리자가 되기 전까지 인터넷 익스플로러, 아웃룩 98 등을 포함한 작은 프로젝트에 참여했다. 마이크로소프트 입사 전 일본에서 중소기업용 솔루션을 개발하는 작은 회사에서 근무했다. BJ는 국제 학술대회에 연사로 참가하고, 저널에 기고하며, 워싱톤 대학의 소프트웨어 테스팅과 테스트 자동화 공개강좌에서 강의한다.


[ 옮긴이의 말 ]

실무에서 확실히 입증된 소프트웨어 테스팅 기법 및 방법을 알고 현재의 테스팅 업무에 활용하고자 한다면 지금 최적의 책을 보고 있다. 역자들도 번역 후 업무에 이 책의 내용을 참고하며 “업무 활용도 높은 책을 번역했다”면서 뿌듯해 하고 있다. 세계 최대 규모의 소프트웨어 회사가 전사적으로 활용하는 테스팅 방법, 자동화 툴, 테스팅 프로세스로 인정받으려면 수많은 부서에서 오랫동안 적용해 효과를 입증해야 한다. 이렇게 입증돼 손에 잡히듯 적용할 수 있는 내용이 이 책을 가득 채우고 있다.

개발자 1명에 테스터 1~2명, ‘테스팅 엑설런스 센터(Testing Center for Excellence)’ 등으로 개발 및 테스팅 분야에서 잘 알려진 마이크로소프트에서 어떻게 테스팅하는지 알려면 해외 컨퍼런스에 고가의 비용을 지불하고 참석했어야 했다. 그러고도 짧은 시간 발표를 듣고 발표가 끝난 후 못내 궁금한 사항을 잘 안되는 영어로 묻고 이해하느라 고생했던 생각이 아련하다. 이 책의 원서인 『How We Test Software at Microsoft』가 나오기 전까지는 말이다. 오랫동안 궁금했던 세계 최대 소프트웨어 기업의 테스팅 프랙티스를 전부는 아니지만 구체적인 단면을 책으로 볼 수 있게 되어 소프트웨어 테스팅을 업으로 살아가는 한 사람으로서 기쁘게 생각한다.

특정한 회사에서 자사 이름으로 자사의 테스팅 프랙티스 책을 쓴다는 것이 매우 당돌하다는 생각을 해본다. 어떤 독자가 특정 기업을 홍보하는 성격이 강한 책을 사서 볼 것인가? 마이크로소프트이니 이런 책을 쓰는 것이 가능하고, 나조차도 같은 이유로 다시는 번역서를 쓰지 않겠다는 결심을 깨고 이 책을 번역하겠다고 나섰다.

국내에 이런 책을 쓸 수 있는 회사가 없음이 아쉽다. 그런 한국 회사가 있어 그 기업 내 테스팅 전문가가 책을 쓰고 그 책을 영문으로 번역하는 일을 했었다면 더 보람찼을 텐데… 현재 국내 소프트웨어 테스팅 수준은 전반적으로 낮고 그 중요성에 대한 인식도 아직은 부족하다. 소프트웨어 테스팅이 전체 개발 계획에서 고려되지 않는 경우도 존재하고, 고려되어도 개발에 밀려 허겁지겁 적당히 야근해가면서 과거의 습성대로 수행하기도 다반사다. 어느 정도 테스팅 시간이 확보되고 여력이 되는 회사도 많이 고민하고 배워가면서 테스팅을 지적이고 현명하게 수행하고 체계화하는 노력에는 인색하다. 완성도 높은 자사 고유의 테스팅 방식과 기술을 개발해 수준 높은 테스팅을 수행하고 있다기보다는 선진국을 허겁지겁 쫓아가고 있는 수준에 머물고 있다.

어차피 완벽한 테스팅은 존재하지 않는다. 테스팅에는 만병통치약이 있다기보다는 기본적인 이론으로 무장하고 경험으로 보완된 어느 정도 탄탄한 업계의 모범 사례(Best Practice)만이 존재할 뿐이다. 이 책에서 다루는 테스팅 관련 내용도 같은 맥락에 있다. 이는 쉬운 것 같지만 실제로는 무척 도전적이다. 그렇다고 그렇게 어려운 것만도 아니다. 테스팅에 참여하는 개발 관련자의 의지와 경영층의 적절한 지원이 뒷받침되면 해볼 만하다.

마이크로소프트처럼 경영층이 테스팅의 중요성을 인식하고 어느 정도는 충분한 리소스가 제공되는 환경에서 테스팅이 일정 수준 이상 완성도 높게 진행되는 것은 당연할 수 있다. 우리에게 이런 지원과 환경이 갖춰진 후 테스팅하라고 한다면 오히려 마이크로소프트보다 더 잘할 수 있다고 생각한다. 부럽지만 특정 회사의 지원과 투자 및 일하는 환경이 좋을 뿐이지 우리라고 못할 대단한 것은 아니라고 본다. 이 책에는 이런 지원과 환경이 갖춰져 ‘실제로 활용’되고 있는 ‘입증된’ 프랙티스가 많다. 그런 과정에서 오랫동안 축적하고 경험해온 그들의 테스팅에 대한 인사이트를 독자 여러분의 것으로 만들었으면 한다.

테스팅에 대한 인식이 열악한 대한민국에서 테스팅을 전업으로 하는 과정은 어려움 투성이다. 또한 개발하면서 테스팅하는 개발자가 체계적인 테스팅을 통해 품질을 확보하는 것은 더더욱 쉽지 않다. 이 책의 내용에서 보는 바와 같이 표준적인 테스팅 이론을 적절히 활용하는 수준이 현재의 세계적인 수준이다. 결국 여러분도 마음 ‘독하게’ 먹고, 열악한 상황에서도 국제 및 업계 표준을 적절히 공부하고 이를 적극적이고 지속적으로 업무에 활용한다면 동일한 수준에 오를 수 있다고 본다. 어렵게 했기 때문에 오히려 더 뼈가 되고 살이 될 수 있다.

이 책은 기본적인 테스팅 이론을 실무에 적절히 적용하고 있는 사례를 담고 있다. 또한 적용하는 과정에서 체득한 다각적인 활동 경험을 진솔하게 기록한 부분이 많아 마치 현장에서 테스팅에 참여했다는 착각을 일으키기도 한다. 예를 들어, 특정한 테스트 설계 기법을 어떻게 적용했고 그 과정에서 어떤 어려움이 있었는지, 자동화 툴을 어떻게 개발해 도입했고 실제적으로 어떤 효과를 봐서 전사에 어떤 방식으로 확산했는지 등 다양한 실 사례를 해당 프로젝트를 진행한 다양한 매니저나 담당자가 에피소드 형태로 서술해 경험을 공유한다.

이 책을 통해 세계 최고의 모범 사례 테스팅을 간접 경험하기 바란다. 그리고 이를 소화하고 한 단계 발전시켜 자사의 테스팅 체계를 구축하고 활용한다면 단기간에 세계적 수준의 테스팅을 수행할 수 있다고 본다(물론, 쉽지는 않을 테니 강한 의지와 적극적인 노력이 반드시 필요하다). 마침 국내에서 ISO 소프트웨어 테스팅 표준을 비롯한 안정화된 높은 수준의 테스팅 프로세스 및 프랙티스가 빠른 속도로 확산되고 있어 우리가 테스팅을 잘할 수 있는 환경이 구축되고 있다. 중소기업을 대상으로는 정부의 테스팅 관련 교육 지원과 컨설팅 제공도 줄을 잇고 있다. 이런 기회를 잘 활용해 해외 테스팅 전문가 들이 존중하고 벤치마킹하는 테스팅 분야의 전문가 또는 개발 과정에서 수준 높게 테스팅하는 차별화된 개발 전문가가 많이 탄생하기 바란다.



[ 옮긴이 소개 ]

권원일
현재 STA컨설팅에서 테스팅에 대한 사명감을 갖고 테스트 컨설턴트 겸 경영자로 일하고 있다. 테스팅 프로세스 심사 및 방법론, 테스팅 국제 표준화(ISO/IEC29119), 유지보수 테스팅, 테스트 메트릭, 테스팅 컨셉의 시각화를 통한 경영층 인식전환, 한국적 테스팅 접근법 개발 등에 관심이 많다. 국내 테스팅 분야의 롤모델이 되는 꿈을 갖고 있다. 그리고 대한민국의 테스팅 수준을 높여 전 세계에 퍼뜨리는 글로벌 비즈니스 성공 목표에 한발씩 다가가고 있다.

이공선
현재 TTA의 SW시험인증팀에서 일하고 있다. 관심분야는 소프트웨어 테스트이며, 특히 IT 관련 신기술과 신제품에 관심이 많다.

김민영
현재 삼성전자 DMC 연구소 SE Lab에서 책임 연구원으로 재직 중이다. 주요 관심분야는 테스트 메니지먼트, 컨버전스(Convergence) 테스팅, 사용성(Usability) 테스팅이다. 대한민국의 후배 테스트 엔지니어 양성을 위해 일조하자는 목표를 가지고 있다.

김윤명
소프트웨어 개발자로 커리어를 시작해 현재 GTOne 에서 테스트 엔지니어로 일하고 있다. 테스팅 방법론에 관심이 많고, 여러 조직의 베스트 프랙티스를 공유할 수 있는 방법을 찾고 있다.

여용구
현재 NHN 비즈니스 플랫폼(Business Platform)의 QA팀에서 일하고 있다. 끝까지 ‘테스터의 야성’을 잃지 않고 조금이나마 QA 분야에 기여하는 것이 바람이다. QA 분야 전문가가 되기 위해 관련 책 100권 읽기를 목표로 하고 있으며, 테스트 자동화 부분에 관심을 갖고 있다.

목차

• 1부 마이크로소프트에 대해
  
• 01장 마이크로소프트의 소프트웨어 엔지니어링
  • 마이크로소프트의 비전, 기업 가치, 높은 선호도의 비결
  • 대규모 소프트웨어 엔지니어링 기업
  • 효율적인 대규모 비즈니스 개발
    • 공유 팀 모델
  • 대기업의 소규모 비즈니스
  • 다양한 엔지니어 고용
    • 엔지니어링 분야
  • 세계적 소프트웨어 개발사를 향해
  • 정리
    
• 02장 마이크로소프트의 소프트웨어 테스트 엔지니어
  • 이름을 붙여볼까?
  • 마이크로소프트의 테스터가 항상 SDET는 아니다
  • 테스터가 더 많아야 한다
    • 학교 방문 채용
    • 업계 경력직 채용
  • 마이크로소프트 SDET 되기
  • 마이크로소프트 엔지니어링 커리어
  • 테스트 부문의 커리어 패스
    • 테스트 아키텍트
    • IC 테스터
    • 관리자가 되는 것이 승진은 아니다
    • 테스트 관리자
  • 정리
    
• 03장 엔지니어링 생명주기
  • 마이크로소프트의 소프트웨어 공학
    • 전통적 소프트웨어 공학 모델
    • 마일스톤
    • 마이크로소프트에서의 애자일
    • 기능 통합
  • 프로세스 개선
    • 마이크로소프트의 정형적 프로세스 개선 시스템
  • 전시상황실에서 소프트웨어 출시
    • 의무 실행
  • 정리: 음식을 다 만들고
    
• 2부 테스팅
  
• 04장 테스트 케이스 작성을 위한 실용적 접근
  • 좋은 소프트웨어 설계와 테스트 설계
  • 테스트 패턴 사용
  • 테스트 시간 추정
  • 테스트 시작
    • 질문하기
    • 테스트 전략 수립
  • 테스트 용이성
    • 테스트 설계 명세서
  • 정상 동작 테스트와 오동작 테스트
  • 테스트 케이스 설계 시 고려해야 할 기타 항목
    • 블랙박스, 화이트박스, 그레이박스
    • 마이크로소프트의 탐색적 테스팅
  • 정리
    
• 05장 기능 테스팅 기법
  • 기능 테스팅의 필요성
  • 동등 클래스 분할
    • 변수 데이터 분할
    • 동등 클래스 분할 동작
    • 파라미터의 서브셋 분석
    • ECP 테스트
    • 동등 클래스 분할 요약
  • 경계 값 분석
    • 경계 값 테스트의 정의
    • 경계 값 분석을 위한 새로운 공식
    • 숨겨진 경계 값
    • 경계 값 분석 요약
  • 조합 분석
    • 조합 테스팅 접근 방법
    • 조합 분석의 적용
    • 조합 분석의 효과
    • 조합 분석 요약
  • 정리
    
• 06장 구조적 테스팅 기법
  • 블록 테스팅
    • 블록 테스팅 요약
  • 결정 테스팅
    • 결정 테스팅 요약
  • 조건 테스팅
    • 조건 테스팅 요약
  • 기본 경로 테스팅
    • 기본 경로 테스팅 요약
  • 정리
    
• 07장 코드 복잡도에 따른 리스크 분석
  • 비지니스 리스크
  • 복잡한 문제
    • 코드 라인 수 측정
  • 사이클로매틱 복잡도 측정
    • 할스테드 메트릭
    • 객체지향 메트릭
    • 사이클로매틱 복잡도가 높다고 반드시 버그가 많은 것은 아니다
  • 복잡도 메트릭 제대로 다루기
  • 정리
    
• 08장 모델 기반 테스팅
  • 모델링 기초
• 모델 테스팅
  • 모델 설계
  • 소프트웨어 모델링
  • 유한 상태 모델 만들기
  • 모델 자동화
• 테스팅을 지원하는 모델링
  • 베이시안 도해 모델
  • 페트리 넷
• 마이크로소프트의 모델 기반 테스팅 툴
  • 스펙 익스플로러
  • 언어와 엔진
  • 모델링 팁
• 정리
• 추천 도서와 툴
  

3부 테스트 툴과 시스템

09장 버그와 테스트 케이스 관리

• 버그 워크플로우
• 버그 추적
  • 버그의 일생
  • 버그 추적 시스템의 속성
  • 버그 리포트를 작성하는 이유
  • 버그 리포트의 구조
  • 버그 선별
  • 버그 리포트의 일반적인 실수
  • 데이터 사용
  • 데이터 오용: 성과 측정으로서의 버그
  • 버그 바
• 테스트 케이스 관리
  • 테스트 케이스란?
  • 테스트 케이스의 가치
  • 테스트 케이스 구조
  • 테스트 케이스 작성 시의 실수
• 테스트 케이스 관리하기
  • 케이스와 포인트: 테스트 케이스 수 세기
  • 테스트 결과 추적과 해석
• 정리
  

10장 테스트 자동화

• 자동화의 가치
  • 자동화냐 아니냐, 그것이 문제로다
• UI 자동화
• 테스트 자동화 구성 요소
• 마이크로스프트에서의 SEARCH
  • 설정
  • 실행
  • 분석
  • 보고
  • 초기화
  • 도움말
• 실행, 자동화, 실행!
  • 모두 연동하기
  • 대규모의 테스트 자동화
  • 일반적인 자동화 실수
• 정리
  

11장 비기능 테스팅

• 기능성을 넘어
• ‘~성’ 테스트하기
• 성능 테스팅
  • 성능 측정 방법
• 스트레스 테스팅
  • 분산 스트레스 테스팅
  • 분산 스트레스 아키텍처
  • 멀티 클라이언트 스트레스 테스트 속성
• 호환성 테스팅
  • 애플리케이션 라이브러리
  • 애플리케이션 검증기
• 자기 개밥 먹기
• 접근성 테스팅
  • 접근성 페르소나
  • 접근성 테스트하기
  • MS 액티브 액세서빌리티를 위한 테스팅 툴
• 사용성 테스팅
• 보안성 테스팅
  • 보안 위협 모델링
  • 퍼지 테스팅
• 정리
  

12장 다양한 툴 활용

• 코드 변경
• 통제하기
  • 변경 추적
  • 무엇이 변경됐나?
  • 왜 변경됐나?
  • 소스 관리를 위한 공간
• 빌드
  • 일일 빌드
• 정적 분석
  • 네이티브 코드 분석
  • 매니지드 코드 분석
  • 단지 또 다른 툴
  • 테스트 코드 분석
  • 테스트 코드가 제품 코드다
• 더 많은 툴
  • 특수한 문제를 위한 툴
  • 모든 사람을 위한 툴
• 정리
  

13장 고객 피드백 시스템

• 테스팅과 품질
  • 정보를 제공하는 테스팅
  • 품질에 대한 이해
• 해결책은 고객
  • 게임에서의 사례
• 윈도우 오류 보고
  • WER 사용 사례
  • 버킷 활용하기
  • 버킷에 쌓인 문제 처리하기
  • 테스트와 WER
• 스마일 전송 프로그램
  • 스마일 전송 프로그램 효과
• 고객과의 연결(커넥트)
• 정리
  

14장 소프트웨어 플러스 서비스 테스팅

• 두 가지 부문: 서비스와 테스트 기법

1절: 서비스

• 마이크로소프트 서비스 전략
• 인터넷 서비스로의 관심 이동
• 라지 스케일에서 메가 스케일로의 성장
• 성장의 발목을 잡는 전력
• 서비스와 패키지 제품
• 독립형에서 계층형 서비스로 이동

2절: S+S 테스팅

• 혁신의 물결
• S+S와 서비스에 대한 테스트 접근 방법 설계
• S+S 테스팅 기법
• 통합 테스팅, 테스트 플래그, 에뮬레이션

S+S에 대한 몇 가지 중요한 생각

• 지속적인 품질 개선 프로그램
• 내가 본 일반적인 버그

정리

4부 앞으로의 전망

15장 문제의 조기 해결

• 결함 분석 자동화
  • 분석 마비 상황의 극복
  • 결함 비교
  • 좋은 로깅 사례
  • 로그 파일의 구조
  • 결함 분석 자동화 통합
• 머신 가상화
  • 가상화의 장점
  • 가상 머신 테스트 시나리오
  • 테스트 도중 발생하는 오류
  • 추천하지 않는 테스트 시나리오
• 코드 리뷰와 인스펙션
  • 코드 리뷰의 유형
  • 체크 리스트
  • 리뷰 시 고려 사항
  • 리뷰의 두 얼굴
• 툴이 너무 많아도 문제
  • 간소화, 재사용, 재활용
  • 무엇이 문제인가?
  • 공개 개발
• 정리
  

16장 테스팅의 미래

• 전향적 사고의 필요성
  • 한걸음 물러서서 앞을 내다보기
  • 품질 문화를 위한 노력
  • 테스팅과 품질 보증
  • 누가 품질의 주인인가?
  • 품질 비용
  • 테스트의 새로운 역할
• 테스트 리더십
  • 마이크로소프트 테스트 리더십 팀
  • 테스트 리더십 의장
  • 테스트 리더십 활동
  • 테스트 아키텍트 그룹
• 테스트 엑설런스 팀
  • 공유
  • 도움
  • 소통
  • 미래 주목하기
  • 마이크로소프트 테스트 엑설런스 팀의 감독
  • 리더십 3원소

[ p21 목차 8장 부분 페이지 전체 수정 ]

08장 모델 기반 테스팅 229
     모델링 기초 230
     모델 테스팅 232
     모델 설계 232
     소프트웨어 모델링 234
     유한 상태 모델 만들기 238
     모델 자동화 238
     테스팅을 지원하는 모델링 246
     베이시안 도해 모델 246
     페트리 넷 247
     마이크로소프트의 모델 기반 테스팅 툴 248
     스펙 익스플로러 249
     언어와 엔진 255
     모델링 팁 259
     정리 260
     추천 도서와 툴 261

수정페이지 PDF 다운로드>>

[ p120 10행 ]
바로 수정이 돼야 하는 버그했다. → 바로 수정이 돼야 하는 버그였다.