추가 적립 안내

『지식 제로부터 배우는 소프트웨어 테스트』는 엔지니어로서의 마음가짐이나 소프트웨어 테스트를 할 수 있는 것과 할 수 없는 것 등 초보자가 먼저 알아야 할 것들에 대해서 설명한 책이다. 또한 반드시 실시하는 각종 테스트 기법의 기초와 포인트, Agile 등 새로운 개발 방법을 지원하는 테스트의 생각 등 테스트 기술자에게 필수적인 지식과 정보를 친절한 설명과 예시로 알기 쉽게 해설했다.

테스트 엔지니어 필독서로써 베스트셀러가 8년만에 다시 등장!
엔지니어로서의 마음가짐이나 소프트웨어 테스트를 할 수 있는 것과 할 수 없는 것 등 초보자가 먼저 알아야 할 것들에 대해서 설명합니다.
또한 반드시 실시하는 각종 테스트 기법의 기초와 포인트, Agile 등 새로운 개발 방법을 지원하는 테스트의 생각 등 테스트 기술자에게 필수적인 지식과 정보를 친절한 설명과 예시로 알기 쉽게 해설 한 책입니다.
테스트 기술자의 입문 서적이고 최적의 기본서로서, 소프트웨어 개발 현장의 요구에 입각한 내용을 엄선했고, 더 쉽게 업그레이드했습니다. 소프트웨어 테스트에 종사하는 초급 엔지니어나 테스트 기술자를 육성 및 양성하는 리더 층에도 알맞은 책입니다.

이 책의 특징

#. 애자일·클라우드 시대의 소프트웨어 테스트

#. 신뢰와 실적 넘버원의 인기 입문서! 리뉴얼판 등장!

#. 테스트 업계 일인자가 말하는 현장에서 꼭 필요한 방법 + 필수 이론

#. 애플리케이션 개발, 시스템 개발, 임베디드 개발, 거기에 애자일과 클라우드까지

#. 다양한 테스트를 통해 중요한 지식을 알기 쉽고 배우기 쉽도록

-출판사 리뷰-
이미 출간된 《지식 제로부터 배우는 소프트웨어 테스트》도서는 일본 아마존 베스트셀러입니다. 테스트 업계에서는 '돼지 책'(이전 판 표지 그림의 벌레가 돼지처럼 보임)이라 불리거나 ‘글자가 큼에도 비쌈’ 등 외형적인 비판은 많았습니다만, 하지만 내용에 대해서는 비판이 없었습니다.
독자분들에게 인정을 받았다는 것은 사실인듯하므로 지엽적인 부분은 건드리지 않은 채 개정판이 나왔습니다.
이 책에서는 어려운 내용을 간단히 쓰고자 노력했습니다. 또한, 시중에 나온 테스트 관련 서적 중에는 자신의 실제 체험에서의 경험만을 다룬 것이 많습니다. 이 책에서는 이를 방지하고자 항상 참고 문헌을 참고하여(필자의 경험만을 전한다면 단순한 실패 사례집이 될 것입니다.) 올바른 소프트웨어 세계를 전달하고자 노력했습니다.

[개정판에서 달라진 부분]
이번 판에서 달라진 부분을 정리하고자 합니다. 이전 판과 달리 소프트웨어 테스트 세상도 많이 달라졌습니다. 그 당시는 최선이라고 생각했으나 지금의 시대와 맞지 않는 부분이라면 과감히 삭제하고 시대가 요구하는 것들을 추가했습니다.

[탐색적 테스트(4장)]
탐색적 테스트는 이전 판이 나왔던 때부터 있었던 것으로, 탐색적 테스트를 제창한 Cem Kaner가 스승이었기도 하므로 다루었어야 했었지만, 일본에서는 그리 널리 알려지지 않아서 이전 판에서는 일부러 포함하지 않았었습니다. 그 후 일본에서도 조금씩 알려지기 시작하였으며 대규모·단기간 개발에서는 유용하다고 생각하므로 이번에 추가하게 되었습니다.

[신뢰성 테스트]
눈물을 삼키고 ‘MTBF (평균고장간격: Mean Time Between Failure)’ 등을 포함했습니다(5.4 등). 소프트웨어의 품질과 관련된 사람으로서 소프트웨어 신뢰성의 정의를 모른다는 것도 좀 그렇기도 해서입니다(실제로 잘 모르는 사람도 많습니다만…).

[데이터 흐름 테스트]
데이터 흐름 테스트는 강력한 테스트 방법입니다만, 이를 지원하는 도구가 없다는 것과 망라 테스트와 마찬가지의 접근 방식이므로 제외했습니다.

[정적 해석 도구]
정적 해석 도구의 진화는 놀라우며 그 효용과 투자 대비 효과는 아주 뛰어납니다만, 해마다 달라진다는 점을 고려하여 해당 장을 삭제했습니다(다만, 보안에 관한 설명은 남겨 두었습니다[5.3.4]). 2013년 현재 C/C++와 관련해서는 Coverity Prevent나 GRAMMATECH CodeSonar*라는 것이 유용하며, Java와 관련해서는 FindBugs[ANE08] 등의 오픈 소스 도구가 몇 가지 있으므로 선택하고자 할 때는 최신 정보를 참고하시기 바랍니다.

[새로운 장]
'그래도 테스트가 잘 안 되는 분께'라는 장을 추가했습니다(9장). 실제 학자가 생각하는 소프트웨어 테스트와 소프트웨어 테스트 실무 담당자가 생각하는 것과의 사이에는 괴리가 있습니다. 이 장에서는 학자이자 실무자인 필자의 경험담(실패담)을 설명합니다.

[용어와 관련하여]
용어는 많은 부분 ISTQB (International Software Testing Qualifications Board)를 기준으로 했습니다. 그러나 ISTQB와 테스트 업계에 알려진 논문과 용어가 다를 때는 논문에 사용한 것을 채택하기도 했습니다. 또한, 책에서 용어가 통일되지 않을 때 필자의 판단으로 다른 용어를 사용한 곳도 있습니다. 이럴 때는 각주를 이용하여 함께 적도록 하겠습니다.

1장 시작하며
1.1 테스트를 시작하기 전에 - ‘버그’란 무엇인가?
1.2 버그 때문에 일어난 우주 개발 사고 - 소프트웨어 불량이란?
1.3 버그 때문에 일어난 우주 개발 사고
1.4 테스트 담당자의 마음가짐
- 선배로부터 배우는 소프트웨어 테스트 비법
1.5 완전무결한 소프트웨어 테스트가 가능한가?
- 100만 번의 테스트조차도 충분하다고는 말할 수 없음
1.6 소프트웨어 테스트 실력 점검 - 당신의 테스트 능력 확인

2장 소프트웨어 테스트의 기본 - 화이트박스 테스트
2.1 화이트박스 테스트란? - 프로그램 내부 구조를 철저하게 분석
2.1.1 어떤 테스트 방법이 효과적인가?
2.2 프로그램의 동작 상태를 테스트 - 제어 흐름 테스트
2.3 인기 게임 소프트웨어의 버그
2.4 스테이트먼트 커버리지
2.5 브랜치 커버리지
2.6 커버리지 기준
2.6.1 커버리지 테스트에 포함되지 않은 코드
2.7 커버리지 테스트로 검출할 수 없는 버그
2.7.1 프로그램 루프
2.7.2 요구 사항 자체가 틀렸거나 기능이 준비되지 않은 버그
2.7.3 데이터와 관련된 버그
2.7.4 멀티 태스크나 인터럽트 관련 버그
2.8 커버리지 테스트의 함정
2.9 화이트박스 테스트의 부활(TDD)
2.9.1 애자일이란 것
2.9.2 TDD 단위 테스트 작성
2.9.3 리팩토링(코드 청소)

3장 엔지니어가 자주 사용하는 방법
3.1 블랙박스 테스트의 기본 - 등가 분할과 경계값 분석
3.1.1 간단한 등가 분할·경계값 분석의 예
3.2 어떤 입력이라도 바르게 처리하려면 - 등가 분할법
3.2.1 테스트 케이스 작성 - 아주 강력한 테스트 케이스
3.2.2 테스트 케이스 수를 줄이려면 - 실천적인 테스트 케이스
3.3 버그가 있는 곳 찾기 - 경계값 분석법
3.3.1 테스트 케이스 작성
3.3.2 경계를 테스트하려면 - On-Off 포인트법
3.3.3 경험칙에 따른 테스트 케이스
3.4 복잡한 입출력을 위한 데이터 - 디시전 테이블
3.5 GUI 테스트 - 상태 전이 테스트
3.5.1 상태 전이란?
3.5.2 상태 전이 테스트에서 발견할 버그
3.6 원숭이도 할 수 있는 테스트? - 무작위 테스트
3.7 정리

4장 탐색적 테스트
4.1 테스트 케이스 기반 테스트 - vs. 탐색적 테스트
4.1.1 테스트 설계·케이스 작성을 초기 단계에서 수행할 때의 단점
4.1.2 같은 테스트 케이스를 수없이 실행할 때의 단점
4.2 탐색적 테스트 예제
4.2.1 기준 결정
4.2.2 탐색적 테스트의 태스크 실행
4.3 비기능 요구에 대한 탐색 테스트 접근 방법
4.4 탐색적 테스트 정리

5장 모든 기능을 테스트하고 가장 어려운 테스트에 도전
- 비기능 요구 테스트
5.1 비기능 요구 테스트의 어려움
5.2 기대 대로 특성을 이끌어 내려면 - 성능 테스트
5.2.1 성능 테스트 5단계
5.3 공격에 견디는 소프트웨어 구축 - 보안 테스트
5.3.1 보안 테스트의 중요성
5.3.2 공격의 역사와 종류
5.3.3 모듈 지향 테스트
5.3.4 정적 분석 도구
5.3.5 기본적인 테스트 방법
5.4 신뢰성을 제대로 이해하고 있는지? - 신뢰도 성장 곡선

6장 소프트웨어 테스트 운영의 기본 - 테스트 성공의 방정식
6.1 최악의 소프트웨어 출하를 피하려면 - 비용과 품질의 균형-
6.2 테스트 계획 작성 방법 - IEEE 829 테스트 계획 템플릿
6.2.1 IEEE 829 테스트 계획 템플릿
6.2.2 테스트 계획 문서 번호(Test plan identifier)
6.2.3 참고 자료(Reference)
6.2.4 소개 글(Introduction)
6.2.5 테스트 아이템(Test items)
6.2.6 테스트해야 하는 기능(Features to be tested)
6.2.7 테스트할 필요가 없는 기능(Features not to be tested)
6.2.8 접근 방법(Approach)
6.2.9 인원 계획, 훈련 계획(Staffing and traing needs)
6.2.10 인원과 시간을 어떻게 예상해야 하는가?
6.2.11 일정(Schedule)
6.2.12 테스트 일정은 개발 일정에 의존한다
6.2.13 일정을 관리하는 요령
6.2.14 위험과 대책(Risks and contingencies)
6.2.15 승인(Approvals)
6.2.16 종료 기준
6.2.17 테스트 계획의 이상과 현실
6.3 테스트 케이스 작성 방법 - 효율적인 테스트 케이스 작성과 관리
6.3.1 테스트 케이스 작성 예
6.3.2 테스트 케이스 관리 도구 사용
6.3.3 테스트 케이스는 얼마나 필요할까?
6.4 테스트 케이스 실행 - 어떤 테스트를 어떤 순서로 실행할 것인가?
6.5 테스트 시작 시점 - 테스트 담당자는 어느 단계에서
프로젝트에 참여하는가?
6.6 출하 전날 버그를 발견했을 때의 대처 - 출하 연기를 판단하는 포인트

7장 소프트웨어 품질 관리의 기본 - 소프트웨어 품질 매트릭스
7.1 품질을 눈에 보이도록 하려면? - 매트릭스 선택의 기본
7.1.1 버그의 수를 관리하는 버그 매트릭스
7.1.2 버그 수정에 드는 시간
7.1.3 모듈에서 발견된 버그
7.2 코드 줄 수에서 알 수 있는 의외의 사실 - 소스 코드 매트릭스
7.2.1 코드 줄 수와 버그 밀도
7.3 복잡한 코드일수록 버그가 많음 - 복잡도 트릭스
7.4 Microsoft는 어떤 매트릭스를 사용하는가?
- 올바른 매트릭스 선택 예
7.5 그대여 사람은 측정하지 말라 - 매트릭스를 잘못 사용한 예

8장 테스트 자동화라는 악마 - 왜 자동화는 실패하는가?
8.1 이 자동화 도구는 제 역할을 하나요? - 테스트 자동화의 장단점
8.1.1 테스트 자동화는 왜 실패하는가?
8.2 테스트 담당자가 빠지기 쉬운 함정 - 테스트 자동화의 진짜 문제점

9장 그래도 테스트가 잘 안 되는 분께
9.1 조합 테스트 중지
9.2 품질 낮은 모듈 철저하게 파고들기
9.2.1 Google 알고리즘