탐험적 테스팅(exploratory testing), 애자일 소프트웨어 개발

소프트웨어 개발업에 종사를 하면 원치 않아도 듣게 되는 개발 방법론, 서적을 검색하면 인사이트에서 나온 Agile 시리즈가 가장 구미 당기게 생겼다. 오늘은 다시 애자일을 처음 접했던 초심으로 돌아가 팀원들이 모두 참여하고 관심을 기울여야 하는 테스트 부분을 다시 훑어보기로 했다.

 

 

탐험적 테스팅: 배우고 통찰하며 개선하는 소프트웨어 테스트
 EXPLORE IT, Resduce risk and increase confidence with exploratory testing

 

책을 고르는 방법

책을 접할때 가장 중요한 포인트는 목차(Index)라고 생각한다. 내가 전공관련 목차에서 중점적으로 보는 것은 아래 항목이다.

1. 내가 원하는 내용의 키워드가 있는가?
2. 기승전결을 느낄 수 있는가?
3. 찾아보기가 있는가?
4. 참고 문헌을 표기했는가?
5. 부록이 있는가?

이전에는 추천글, 옮긴이 글을 주로 봤었다. 책을 읽은이들의 주관적 해석과 의견, 글쓴이의 의도들이 진정성이 있고 나에게 필요한지를 가름하기 위해서였다. 하지만 한 주제를 다루는 다수의 책을 접하고, 내가 필요해서 찾아 본 책들이다보니 그들의 말은 나에게 당연히 이 책은 너에게 필요해라는 인상 남겼다고 생각이 들었다.

그래서 좀 더 객관적인 접근을 위해 목차를 나만의 기준을 가지고 책을 접하게 되었다.

 

목차

한국어판 지은이의 글 ix
옮긴이의 글 xii
추천의 글 xv
감사의 글 xvii
머리말 xx

1부 기초 확립하기 1

1장 테스팅과 탐험에 대하여 3
1.1 테스트 수행의 양면성 5
1.2 탐험적 테스팅을 위한 필수 요소들 8
1.3 정해진 시간 안에 탐험하기 12
1.4 실제 적용을 위한 조언 13

2장 탐험을 위한 차터 작성 17
2.1 탐험을 위한 차터 작성의 시초 18
2.2 간단한 차터 양식 20
2.3 좋은 차터란? 23
2.4 차터 작성하기 25
2.5 악몽의 머리기사 게임 33
2.6 차터 미리 계획하기 38
2.7 실제 적용을 위한 조언 39

3장 세심하게 관찰하기 41
3.1 그런데 문워크하는 곰을 보셨나요? 42
3.2 더 깊게 파고 들어가기 45
3.3 테스트 용이성과 보이지 않는 것 보이게 만들기 50
3.4 콘솔과 로그 52
3.5 실제 적용을 위한 조언 54

4장 눈여겨볼 변수 찾아내기 57
4.1 변하는 것들을 담고 있는 변수 59
4.2 교묘하게 숨어 있는 변수와 대참사 62
4.3 변수 찾아내기 66
4.4 언제, 어디서나 나타나는 변수들! 77
4.5 실제 적용을 위한 조언 78

5장 결과를 가지고 판단하기 81
5.1 결코 발생하지 않거나 항상 발생하거나... 82
5.2 사용 가능한 다른 자원들 87
5.3 추정 91
5.4 실제 적용을 위한 조언 95

2부 더 깊게 들어가기 97

6장 순서와 상호 작용 다양하게 바꿔보기 99
6.1 명사와 동사 100
6.2 무작위로 사용하기 104
6.3 퍼소나 105
6.4 실제 적용을 위한 조언 109

7장 개체와 개체들 사이의 관계 탐험하기 111
7.1 개체, 속성 그리고 의존성 찾기 112
7.2 CRUD: 생성하기, 읽기, 변경하기, 삭제하기 116
7.3 데이터 따라가기 121
7.4 실제 적용을 위한 조언 122

8장 상태와 전이 발견하기 125
8.1 상태와 이벤트 구분하기 126
8.2 상태 모델 다이어그램 그리기 130
8.3 상태 모델 가지고 탐험하기 133
8.4 다른 형태로 표현하기: 상태 테이블 137
8.5 실제 적용을 위한 조언 141

9장 소프트웨어 생태계 탐험하기 143
9.1 생태계 다이어그램 그리기 144
9.2 신뢰 경계 151
9.3 만약 ~한다면? 152
9.4 데이터 따라가기 156
9.5 실제 적용을 위한 조언 157

3부 상황에 맞게 판단하기 159

10장 사용자 화면이 없는 곳 탐험하기 161
10.1 API 탐험하기 162
10.2 프로그래밍 언어 탐험하기 167
10.3 웹 서비스 탐험하기 170
10.4 버그 찾아내기 173
10.5 실제 적용을 위한 조언 175

11장 기존 시스템 탐험하기 177
11.1 정찰 세션으로 시작하기 178
11.2 관찰 결과 공유 182
11.3 이해관계자들을 인터뷰해서 궁금증 찾아내기 185
11.4 테스트 기법 선택하기 189
11.5 찾아낸 것들 기록하기 190
11.6 재현 불가능한 끔찍한 버그? 191
11.7 실제 적용을 위한 조언 196

12장 요구 사항 탐험하기 199
12.1 요구 사항 분석 회의에 참여하기 201
12.2 요구 사항 회의에서 해야 하는 것들 206
12.3 요구 사항 논의하면서 차터 작성하기 212
12.4 능동적 읽기 215
12.5 실제 적용을 위한 조언 217

13장 처음부터 끝까지 탐험 적용하기 219
13.1 테스트 전략의 일부분으로서의 탐험 219
13.2 짝 탐험 227
13.3 시스템적인 문제 찾아내기 229
13.4 탐험 추정하기 231
13.5 언제쯤 충분히 탐험했다고 이야기할 수 있을까? 233
13.6 이해관계자들에게 보고하기 235
13.7 유용한 지식들을 정리해서 공유하기 240
13.8 실제 적용을 위한 조언 241

부록1 탐험적 테스팅 기법 면접하기 243
A1.1 면접에서 ‘짝 탐험적 테스팅’ 진행하기 244
A1.2 지원자 평가하기 248

부록2 테스트 휴리스틱 치트 시트 251
A2.1 일반적인 휴리스틱 251
A2.2 웹 휴리스틱 260

 

 

내가 바로 본 책

이 책은 1부~3부로 단계별로 접근할 수 있도록 구성되어 있다.

• 1부는 기초 : 탐험적 테스팅을 위한 가이드와 차터에 대한 설명, 그리고 차터를 좀 더 구체적으로 다루면서 다음을 준비하는 자세를 알려준다.
• 2부는 심화 : 심화라는 표현이 거창하긴 하지만 다양한 기법을 설명하여 몸소 체감할 수 있도록 내용이 구성되어 있다. 경험이 부족하여 품질팀장을 찾아가 이것저것 물어보면서 공부했던 기억이 난다.
• 3부는 실전 : 테스팅 상황을 부여하고 2부에서 언급한 기법을 바탕으로 어떻게 탐험적 테스팅을 진행해갈 수 있을지 실전 사례이다. 결함을 찾아내는 것에서 끝나는 것이 아니라 공유를 통해 지속적으로 이어갈 수 있도록 안내하고 있다.

나는 이 책의 2부를 접하면서, 나의 기본 지식이 얼마나 부족한지를 깨닫고 다시 원점으로 돌아가 용어부터 다시 공부했던 기억이 난다. 그리고 이해가지 않거나 풀리지 않는 부분은 품질팀장을 잡아두고 한 참을 물어가며 하나씩 풀어나갔다.

 

머릿말에는 이런 글이 적혀있다.

이 책은 소프트웨어 테스팅에 관한 책이기 때문에, 아마도 테스터를 위한 책이라고 생각하기 쉽다. 맞다. 테스터를 위한 책이다. 하지만 테스터만을 위한 책은 아니다. 나는 신뢰할 만하고 견고한 소프트웨어를 만드는 데 관심이 있는 모든 사람을 위해 이 책을 "썼다. 거기에는 프로그래머, 비즈니스 분석가, 제품 관리자가 포함될 뿐 아니라, 심지어 보통 소프트웨어가 거의 다 완성된 후에야 소프트웨어를 사용해볼 수 있는 고객 지원 담당자도 포함된다. (중략)
간단히 말해, 소프트웨어를 만들거나, 소프트웨어 명세서를 작성하거나, 직접 프로그래밍을 하거나, 소프트웨어를 검증하거나, 소프트웨어를 지원하는 일에 관련되어 있다면, 이 책은 여러분을 위한 책이다.

 

나는 프로젝트 매니저이다. 이 책의a 저자의 의도에 공감한다.
프로젝트는 언제나 불활실한 환경에서 시작을 한다. 고객에게 완벽한 소프트웨어 산출물을 제공할 수 는 없어도 예상되는 문제가 있는 산출물을 제공할 수는 없다. 그래서 소프트웨어를 만드는데 참여하는 모두가 테스터의 관점에서 바라보는 눈을 가지길 희망한다. 나 또한 리스크 관리를 위해 테스팅을 공부했다.

그리고 간혹 혼동하는 경우가 있는것 같은데 탐험적 테스팅을 아무것도 없는 상태에서 경험 기반으로 마구잡이식 테스트가 아니다. 경험과 소프트웨어를 분석한 기반 데이터를 가지고 차터를 작성하여 계획적으로 진행하는 고급 테스팅 기법임을 알아두었으면 한다. 즉 개인의 의지와 책임을 강조하는 테스팅 기법이다.

 

 

 

책이 알려주는 주요 포인트

1. 테스트 수행의 양면성 : 확인하기와 탐험하기 어느 하나만 있어서는 충분하지 않다.

• 확인하기 : 소프트웨어가 주어진 환경과 조건에서, 의도한 대로 동작하는가?
• 탐험하기 : 다른 위험 요소들이 있는가?

2. 테스트 설계하기 > 테스트 수행하기 > 테스트를 통해 학습하기 > 학습을 바탕으로 테스트 방향 조정하기

3. 차터의 시초 : 미국 세 번째 대통령 토머스 제퍼슨이 탐험가인 루이스와 클라크에게 임무를 맡기며 전달한 편지

• 어디를 탐험해야 하는가
• 무엇을 가지고 가야 하는가
• 어떤 정보를 찾아야 하는가
• 차터의 기본 : 목표, 자원, 정보!!

4. 생태계 다이어그램 그리기

• 1단계 : 인터페이스 그리기
• 2단계 : 외부 의존 관계 나타내기
• 3단계 : 내부 채우기

5. 실제 적용을 위한 조언 : 챕터의 마짐막 항목으로 앞서 설명한 내용을 짚어주고 넘어간다.

6. "명사와 동사" 기법 : 소프트웨어와 상호 작용함에 있어 무작위라는 개념을 적용하는 방법으로 미처 생각지못한 정보나 힌트를 얻을 수 있다.

• 명사와 동사를 찾아낸다
• 명사와 동사를 하나씩 무작위로 선택하여 문장을 만들어 수행해본다. 
• 만들어진 문장을 무작위로 선택해 순서대로 수행해본다.

7. CRUD, 처음/중간/끝, 인터럽트, 리버스, 일부/없음/모두, 0/1/다수, 0의 법칙, 뒤로가기/앞으로 가기/히스토리

8. 요구 사항 분석 회의에 참여하기. 요구사항 회의에서 서로간의 생각하는 비즈니스 가치와 기대치가 다를 수 있고 이는 유즈케이스 기반의 테스트 리뷰를 통해 조정할 수 있다. 그래서 테스터는 요구 사항 분석 회의에 참여해야 한다.

 

소프트웨어 품질의 정의 (ISO/IEC 25010 품질특성)

 

소프트웨어 요구 공학, Requirement Engineering