지식 제로부터 배우는 소프트웨어 테스트

지식 제로부터 배우는 소프트웨어 테스트
테스트 업계 일인자가 말하는 현장에서 꼭 필요한 방

[ 리뷰 ]

소프트웨어 테스트와 관련하여 

최근 품질 관련 업무를 하게 되어 관련 도서를 많이 읽고 있는데,

그 중에서 가장 지루하지 않고, 재밌고, 내용이 알찬 책 같다.

ISTQB 시험도 봐야 하는데, '개발자도 알아야할 소프트웨어 테스팅 실무' 책을 읽기 전에,

이 책을 먼저 읽어 볼 것을 추천한다.

전반적인 내용을 거부감 없이 습득할 수 있고, 용어도 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 알고리즘