개념
세 가지를 동시에 한다
탐색적 테스팅의 표준적인 정의는 **"테스트 설계와 테스트 실행을 동시에 수행하며, 그 결과에서 배운 것을 다음 테스트 설계에 실시간으로 반영하는 활동"**이다 (James Bach, Cem Kaner). 핵심은 학습·설계·실행이 분리되지 않고 동시에 일어난다는 것이다.
- 스크립트 테스트: 미리 ①설계 → ②실행이 완전히 분리되어 있다. 실행자는 적힌 대로만 한다.
- 탐색적 테스팅: 실행하면서 방금 본 것에서 배우고(학습), 그 배움으로 다음에 뭘 할지 그 자리에서 정한다(설계), 그리고 바로 해본다(실행) — 이 세 가지가 루프처럼 돈다.
즉흥적 클릭과는 다르다
"탐색적 테스팅 = 아무렇게나 눌러보는 것"이라는 오해가 흔하다. 사실은 반대다. 탐색적 테스팅은 규율이 있다 — 목표(차터, 다음 레슨)가 있고, 시간이 제한되어 있고(시간 상자), 무엇을 봤고 무엇을 궁금해하는지 기록한다. 목표도 없이 정말 아무렇게나 눌러보는 건 **애드혹 테스팅(Ad Hoc Testing)**이라고 따로 부른다 — 애드혹은 구조가 없어서 재현도, 보고도, 커버리지 판단도 어렵다. 탐색적 테스팅은 애드혹보다 구조화되어 있지만, 스크립트 테스트보다는 유연하다 — 그 중간 지점이다.
모듈 3(레슨 8)의 경험 기반 기법과 다른 점
모듈 3에서 배운 오류 추정·체크리스트는 미리 목록을 써두고 그대로 적용한다. 탐색적 테스팅은 목록 없이, 방금 본 것을 근거로 다음 행동을 그 자리에서 결정한다. 체크리스트를 눈앞에 두고 하나씩 확인하는 게 아니라, "방금 이 화면에서 이상한 걸 봤으니 여기를 더 파봐야겠다"는 식으로 진행한다. 둘은 경쟁 관계가 아니라 — 체크리스트로 기본을 훑고, 탐색적 테스팅으로 그 너머를 파고드는 식으로 함께 쓰인다.
시간 상자(Time-boxing)
탐험은 무한정 하지 않는다. 보통 60~90분 단위로 시간을 정해두고, 그 안에서 집중한다. 시간 상자가 없으면 탐험이 흐지부지 늘어지거나, 방향을 잃기 쉽다. 시간 상자 안에서 무엇을 탐험할지 정하는 게 차터다 — 다음 레슨에서 자세히 다룬다.
왜 스크립트만으로는 부족한가
스크립트 테스트는 미리 생각해둔 것만 확인한다. 명세 기반 기법(모듈 3)으로 아무리 꼼꼼히 설계해도, 애초에 "생각하지 못한" 조합이나 상황은 스크립트에 안 들어간다. 탐색적 테스팅은 정의상 이 사각지대를 노린다 — 실행하면서 실시간으로 "어? 이건 뭐지?"를 따라가는 유일한 방법이기 때문이다.
실무에서 왜 필요한가
실무 결함의 상당수는 "아무도 그 케이스를 스크립트로 안 써봤기 때문에" 존재한다. 아무리 방대한 테스트 케이스 목록도 사람이 미리 상상한 것의 한계 안에 있다. 탐색적 테스팅은 그 한계 밖의 결함을 잡는 유일한 방법이라, 릴리즈 전 마지막 안전망 역할을 한다. 또한 새 기능이 처음 나왔을 때, 아직 스크립트가 없는 시점에도 즉시 테스트를 시작할 수 있다는 실용적 장점도 크다.
실습 과제
과제 1 — 세 가지 구분하기 (10분)
다음 세 활동을 스크립트 테스트, 탐색적 테스팅, 애드혹 테스팅 중 무엇인지 분류한다.
- 미리 작성된 테스트 케이스 문서를 열어 한 줄씩 따라 클릭하며 확인한다.
- "결제 흐름에서 할인 계산이 맞는지 확인해보자"는 목표로 30분간 이것저것 눌러보며, 이상한 걸 발견하면 그 주변을 더 파본다.
- 목표나 시간 제한 없이 그냥 앱을 이리저리 눌러본다.
과제 2 — 세 가지 동시 수행 상상하기 (10분)
익숙한 앱(쇼핑몰이든 SNS든) 하나를 떠올려, "장바구니" 기능을 5분간 탐험한다고 상상한다. 첫 번째로 무엇을 할지, 그 결과를 보고 무엇을 배울 수 있을지, 그 배움으로 두 번째 행동을 어떻게 정할지 — 이 루프를 2~3단계 적어본다.
자가 체크리스트
- 탐색적 테스팅을 "학습·설계·실행이 동시에 일어나는 활동"으로 정의할 수 있다
- 탐색적 테스팅과 애드혹 테스팅의 차이(구조의 유무)를 설명할 수 있다
- 탐색적 테스팅과 경험 기반 기법(모듈 3)의 차이(즉흥성 vs 미리 정한 목록)를 설명할 수 있다
- 시간 상자가 왜 필요한지 설명할 수 있다
- 스크립트 테스트만으로 부족한 이유를 "미리 생각한 것만 확인한다"는 한계로 설명할 수 있다
흔한 실수
- 탐색적 테스팅을 "준비 없이 그냥 하면 되는 것"으로 오해한다. 목표와 시간 제한이 없으면 애드혹이지 탐색적 테스팅이 아니다.
- 탐색적 테스팅이 스크립트 테스트를 완전히 대체한다고 생각한다. 둘은 상호 보완적이다 — 스크립트는 재현성과 회귀 안전망을, 탐색적 테스팅은 사각지대 발견을 담당한다.
- 탐험 중 무엇을 봤는지 기록하지 않는다. 나중에 "뭘 확인했었지?"를 기억에만 의존하면, 발견한 것도 놓치고 보고도 부실해진다.
참고 자료
- James Bach & Michael Bolton, "Exploratory Testing 3.0" — 탐색적 테스팅의 현대적 정의를 정리한 에세이
- Elisabeth Hendrickson, Explore It! — 탐색적 테스팅 실무의 대표적인 입문서. 이 모듈 전체가 이 책의 접근을 많이 참고한다
- ISTQB Foundation Level Syllabus — Exploratory Testing — 경험 기반 기법 중 하나로서의 공식 정의