개념
쉬운 비유로 먼저 — 지도와 탐험
낯선 도시에 도착했다고 하자. 두 가지 방식이 있다.
하나. 출발 전에 짠 코스를 그대로 따른다. 9시 박물관, 11시 성당, 1시 시장. 적어 온 대로 움직이고, 다 돌면 끝이다. 무엇을 봤는지 정확히 말할 수 있고, 다음 사람에게 같은 코스를 넘겨줄 수도 있다. 대신 코스에 없던 골목은 영영 못 본다.
둘. 큰 목표만 들고 나선다 — "오늘 오전은 구시가지를 본다". 걷다가 사람들이 몰린 골목이 보이면 들어가 보고, 거기서 본 간판 때문에 방향을 튼다. 적어 온 코스에는 절대 없었을 것을 만난다. 대신 아무 기록도 안 남기면 "재밌었다" 말고는 할 말이 없다.
탐색적 테스팅은 둘째 방식에 기록과 시간 제한을 붙인 것이다. 목표가 있고, 시간이 정해져 있고, 무엇을 봤고 무엇이 궁금한지 적는다. 그래서 "아무렇게나 돌아다닌 것"과 달리 결과를 남에게 설명할 수 있다.
이 비유를 기억해 두면 이 모듈 전체가 쉬워진다. 앞으로 배울 것들이 전부 이 탐험의 도구다 — 차터(레슨 2)는 "오늘 오전은 구시가지" 에 해당하는 목표 선언이고, 휴리스틱(레슨 14)은 "골목이 보이면 들어가 본다" 같은 경험칙 묶음이며, 세션 노트는 걸으면서 적는 메모다.
세 가지를 동시에 한다
탐색적 테스팅의 표준적인 정의는 "테스트 설계와 테스트 실행을 동시에 수행하며, 그 결과에서 배운 것을 다음 테스트 설계에 실시간으로 반영하는 활동" 이다 (James Bach, Cem Kaner). 핵심은 학습·설계·실행이 분리되지 않고 동시에 일어난다는 것이다.
- 스크립트 테스트: 미리 ①설계 → ②실행이 완전히 분리되어 있다. 실행자는 적힌 대로만 한다.
- 탐색적 테스팅: 실행하면서 방금 본 것에서 배우고(학습), 그 배움으로 다음에 뭘 할지 그 자리에서 정한다(설계), 그리고 바로 해본다(실행) — 이 세 가지가 루프처럼 돈다.
즉흥적 클릭과는 다르다
"탐색적 테스팅 = 아무렇게나 눌러보는 것"이라는 오해가 흔하다. 사실은 반대다. 탐색적 테스팅은 규율이 있다 — 목표(차터, 다음 레슨)가 있고, 시간이 제한되어 있고(시간 상자), 무엇을 봤고 무엇을 궁금해하는지 기록한다. 목표도 없이 정말 아무렇게나 눌러보는 건 애드혹 테스팅(Ad Hoc Testing) 이라고 따로 부른다 — 애드혹은 구조가 없어서 재현도, 보고도, 커버리지 판단도 어렵다. 탐색적 테스팅은 애드혹보다 구조화되어 있지만, 스크립트 테스트보다는 유연하다 — 그 중간 지점이다.
세 가지를 한 표로 놓고 보면 경계가 분명해진다.
| 스크립트 테스트 | 탐색적 테스팅 | 애드혹 테스팅 | |
|---|---|---|---|
| 목표 | 미리 적힌 케이스 | 차터(한 문장 목표) | 없음 |
| 시간 | 케이스를 다 돌 때까지 | 정해 둔 시간 상자 | 정해지지 않음 |
| 다음 행동을 정하는 것 | 문서 | 방금 본 것 | 그때의 기분 |
| 기록 | 케이스별 합격·불합격 | 세션 노트 | 대개 없음 |
| 재현 | 쉽다 | 노트가 있으면 가능 | 어렵다 |
| 커버리지를 말할 수 있나 | 숫자로 가능 | 무엇을 봤는지 말로 가능 | 불가능 |
가운데 칸이 이 모듈 전체의 내용이다. 애드혹과 가르는 것은 목표·시간·기록 세 가지이고, 스크립트와 가르는 것은 다음 행동을 무엇이 정하느냐다.
한 가지 오해를 미리 깨 두자. 애드혹이 항상 나쁜 것은 아니다. 새로 받은 빌드를 5분간 눌러 보며 감을 잡는 것은 쓸모가 있다. 다만 그 5분을 "테스트했다" 고 보고하면 안 된다 — 무엇을 봤는지 말할 수 없기 때문이다.
모듈 3(레슨 8)의 경험 기반 기법과 다른 점
모듈 3에서 배운 오류 추정·체크리스트는 미리 목록을 써두고 그대로 적용한다. 탐색적 테스팅은 목록 없이, 방금 본 것을 근거로 다음 행동을 그 자리에서 결정한다. 체크리스트를 눈앞에 두고 하나씩 확인하는 게 아니라, "방금 이 화면에서 이상한 걸 봤으니 여기를 더 파봐야겠다"는 식으로 진행한다. 둘은 경쟁 관계가 아니라 — 체크리스트로 기본을 훑고, 탐색적 테스팅으로 그 너머를 파고드는 식으로 함께 쓰인다.
시간 상자(Time-boxing)
탐험은 무한정 하지 않는다. 보통 60~90분 단위로 시간을 정해두고, 그 안에서 집중한다. 시간 상자가 없으면 탐험이 흐지부지 늘어지거나, 방향을 잃기 쉽다. 시간 상자 안에서 무엇을 탐험할지 정하는 게 차터다 — 다음 레슨에서 자세히 다룬다.
한 세션이 실제로 어떻게 흘러가는가
말로만 들으면 여전히 막연하다. 60분 세션 하나를 그대로 따라가 보자. 쇼핑몰의 쿠폰 적용 을 탐험한다고 하자.
차터: 쿠폰 적용 화면에서 할인 금액이 잘못 계산되는 조건을 찾는다 (60분)
00분 정상 경로부터. 1만원 쿠폰을 3만원 주문에 적용 → 2만원. 맞다.
(학습: 기본은 동작한다. 여기서 더 볼 것은 없다)
05분 "그럼 반대는?" 1만원 쿠폰을 5천원 주문에 적용 → 0원. 합리적이다.
그런데 **쿠폰이 소모됐다.** 5천원짜리 주문에 1만원 쿠폰을 쓰면
5천원이 날아간다.
(설계: 이건 결함인가 정책인가? → 질문 목록에 적어 둔다)
12분 "취소하면?" 그 주문을 취소해 본다 → 쿠폰이 돌아오지 않는다.
(학습: 쿠폰 복구 경로가 의심스럽다. 여기를 판다)
18분 정상 금액 주문을 쿠폰으로 결제 → 취소 → 쿠폰 복구됨. 돌아온다.
(학습: 부분 사용된 쿠폰만 안 돌아오는 것 같다 → 가설이 생겼다)
25분 가설 검증. 1만원 쿠폰 / 7천원 주문 → 취소. 역시 안 돌아온다.
1만원 쿠폰 / 1만원 주문 → 취소. 돌아온다.
**경계가 보인다 — 주문액이 쿠폰액보다 작을 때만 복구가 안 된다.**
32분 재현 절차를 다듬어 적는다. 이건 리포트로 나갈 것이다.
38분 주변을 더 본다. 쿠폰 두 장 동시 적용은? 유효기간 당일은?
다른 결제수단과 섞으면?
(세 가지 다 못 해 봤다 → 다음 차터 후보로 적어 둔다)
55분 노트 정리. 발견 1건, 질문 2건, 못 본 영역 3건.
60분 끝.여기서 봐야 할 것이 세 가지다.
첫째, 다음 행동이 전부 직전 결과에서 나왔다. 5분의 "쿠폰이 소모됐다" 가 12분의 취소 시도를 불렀고, 18분의 비교가 25분의 가설 검증을 불렀다. 이 사슬은 미리 적을 수 없다. 5분에 무엇을 볼지 모르는 상태에서 12분의 케이스를 쓸 방법이 없기 때문이다.
둘째, 발견 1건을 위해 쓴 55분 중 대부분은 "아무것도 안 나온" 시간이다. 이것이 정상이다. 탐색은 확률 게임이고, 그래서 시간 상자가 필요하다 — 안 그러면 "조금만 더" 하며 하루가 간다.
셋째, 끝에 남은 것이 결함 1건이 아니라 네 가지다. 발견 1건, 답을 받아야 할 질문 2건, 다음에 볼 영역 3건, 그리고 "여기는 봤다" 는 기록. 마지막 것이 없으면 다음 사람이 같은 곳을 또 돈다.
끝나고 무엇을 남기나 — 세션 노트
기록이 없으면 탐색적 테스팅은 애드혹과 구별되지 않는다. 그렇다고 모든 클릭을 적으라는 뜻은 아니다. 다섯 칸이면 충분하다.
| 칸 | 적는 것 |
|---|---|
| 차터 | 이 세션의 목표 한 문장 |
| 시간 | 언제부터 언제까지, 실제로 몇 분 |
| 본 것 | 어느 영역을 어떤 조건으로 훑었는가 |
| 발견 | 결함 후보. 재현 절차는 따로 리포트로 |
| 질문·못 본 것 | 답을 받아야 할 것, 시간이 없어 못 본 영역 |
마지막 칸이 실무에서 가장 값지다. "못 봤다" 를 적어 두는 사람이 드물기 때문이다. 릴리즈 직전에 "결제 영역은 쿠폰만 봤고 포인트는 못 봤습니다" 라고 말할 수 있는 것과, "결제 테스트했습니다" 라고만 말하는 것은 팀이 지는 위험의 크기가 다르다.
이 양식을 조직 차원으로 키운 것이 세션 기반 테스트 관리(SBTM) 이고, 레슨 13에서 다룬다.
언제 쓰고 언제 쓰지 않나
만능이 아니다. 상황에 따라 효율이 크게 다르다.
| 상황 | 적합한가 | 왜 |
|---|---|---|
| 새 기능이 막 나왔다 | 매우 적합 | 아직 케이스가 없고, 사양도 덜 굳었다 |
| 결함이 몰린 영역을 더 판다 | 매우 적합 | 결함은 뭉쳐서 나온다 |
| 사양이 모호하다 | 적합 | 탐험 자체가 사양 질문을 만들어 낸다 |
| 릴리즈 직전 마지막 점검 | 적합 | 스크립트가 안 보는 틈을 노린다 |
| 매 배포마다 같은 것을 확인 | 부적합 | 회귀는 자동화가 맞다 |
| 규제 증빙이 필요한 시험 | 부적합 | 무엇을 했는지 사전에 확정돼야 한다 |
| 결과를 숫자로 보고해야 한다 | 부분적 | 케이스 수로는 못 센다. 영역과 시간으로 센다 |
마지막 줄이 보고에서 매번 부딪히는 지점이다. 탐색적 테스팅의 산출은 "케이스 200건 중 198건 통과" 가 아니라 "이 영역을 이만큼 보았고, 여기는 못 보았다" 이다. 숫자를 요구받으면 세션 수와 시간, 그리고 영역별 커버 여부로 답한다.
탐험을 잘하는 사람은 무엇이 다른가
같은 60분을 줘도 사람마다 결과가 크게 다르다. 차이를 만드는 것은 손이 아니라 세 가지 습관이다.
하나, 이상한 것을 그냥 지나치지 않는다. 화면이 0.5초 깜빡였거나, 금액 자릿수가 미묘하게 어긋났거나, 버튼이 두 번 눌리는 느낌이 들었을 때 — 초보자는 "그럴 수도 있지" 하고 넘어가고, 숙련자는 멈춰서 한 번 더 해 본다. 결함은 거의 항상 "어? 방금 뭐였지" 뒤에 있다.
둘, 질문을 바꿔 가며 본다. 같은 화면을 봐도 던지는 질문이 다르다. "되나?" 만 묻는 사람과, "안 되게 하려면 어떻게 해야 하지?" 를 묻는 사람의 결과가 다르다. 뒤쪽 질문이 자연스럽게 경계값과 예외 상황으로 데려간다.
셋, 도메인을 안다. 쿠폰 사례에서 "주문액이 쿠폰액보다 작을 때" 를 떠올릴 수 있었던 것은 그 업무가 어떻게 돌아가는지 알기 때문이다. 기술보다 도메인 지식이 탐색의 질을 더 크게 좌우한다. 그래서 이 활동은 경력이 쌓일수록 잘 된다 — 신입에게 던져 두는 일이 아니다.
세 가지 다 가르칠 수 있는 것이다. 첫째는 레슨 4(세심하게 관찰하기), 둘째는 레슨 14(휴리스틱), 셋째는 레슨 11(레거시 시스템 탐험)에서 각각 다룬다.
왜 스크립트만으로는 부족한가
스크립트 테스트는 미리 생각해둔 것만 확인한다. 명세 기반 기법(모듈 3)으로 아무리 꼼꼼히 설계해도, 애초에 "생각하지 못한" 조합이나 상황은 스크립트에 안 들어간다. 탐색적 테스팅은 정의상 이 사각지대를 노린다 — 실행하면서 실시간으로 "어? 이건 뭐지?"를 따라가는 유일한 방법이기 때문이다.
둘을 함께 쓰는 법 — 한 번의 릴리즈에서
"스크립트냐 탐색이냐" 는 질문 자체가 잘못됐다. 실제 릴리즈 한 번에서 둘은 시점을 나눠 쓴다.
| 시점 | 주로 쓰는 것 | 이유 |
|---|---|---|
| 기능이 막 올라왔을 때 | 탐색 | 케이스가 아직 없다. 사양 질문도 여기서 나온다 |
| 사양이 굳은 뒤 | 스크립트 작성 | 탐험에서 배운 것을 케이스로 고정한다 |
| 매 배포 | 자동 회귀 | 사람이 반복할 일이 아니다 |
| 릴리즈 직전 | 탐색 | 자동화가 안 보는 틈을 노린다 |
| 사고가 난 뒤 | 탐색 → 스크립트 | 주변을 파고, 나온 것을 회귀에 넣는다 |
여기서 가장 중요한 줄은 두 번째다. 탐험에서 발견한 것은 반드시 케이스로 고정한다. 안 그러면 같은 결함이 다음 릴리즈에 다시 들어와도 아무도 모른다. 탐험은 찾는 활동이고, 찾은 것을 지키는 것은 스크립트와 자동화의 일이다.
이 순환이 돌기 시작하면 팀의 케이스 목록이 스스로 자란다. 처음에는 기획서에서 뽑은 케이스뿐이지만, 탐험이 한 번 돌 때마다 "실제로 터졌던 것" 이 몇 건씩 들어온다. 그 목록은 기획서에서는 절대 나올 수 없는 것들이고, 그래서 시간이 지날수록 그 팀만의 자산이 된다.
실무에서 왜 필요한가
실무 결함의 상당수는 "아무도 그 케이스를 스크립트로 안 써봤기 때문에" 존재한다. 아무리 방대한 테스트 케이스 목록도 사람이 미리 상상한 것의 한계 안에 있다. 탐색적 테스팅은 그 한계 밖의 결함을 잡는 유일한 방법이라, 릴리즈 전 마지막 안전망 역할을 한다. 또한 새 기능이 처음 나왔을 때, 아직 스크립트가 없는 시점에도 즉시 테스트를 시작할 수 있다는 실용적 장점도 크다.
실무에서 이 활동이 특히 값진 순간이 셋 있다.
하나, 사양이 아직 덜 굳었을 때. 케이스를 쓰려면 "무엇이 맞는 동작인가" 가 정해져 있어야 한다. 그런데 새 기능은 그게 정해지기 전에 동작하는 화면이 먼저 나오는 경우가 많다. 이때 탐험은 케이스를 만드는 대신 질문을 만든다 — 앞의 쿠폰 사례에서 5분에 적은 "이건 결함인가 정책인가" 가 그것이다. 그 질문 하나가 모듈 2에서 배운 요구사항 공백 찾기와 같은 일을 한다.
둘, 결함이 몰린 영역을 더 팔 때. 결함은 고르게 흩어지지 않고 뭉쳐서 나온다. 한 영역에서 두세 건이 나오면 그 주변에 더 있을 확률이 높다. 스크립트는 "케이스 목록을 다 돌면 끝" 이지만 탐험은 나온 곳을 더 팔 수 있다. 모듈 4의 리스크 기반 테스트가 말하는 "위험이 큰 곳에 시간을 더 쓴다" 를 실행 단계에서 하는 방법이다.
셋, 자동화가 다 통과했는데 불안할 때. 회귀 자동화 400건이 전부 초록색인데 뭔가 미심쩍은 상황이 실제로 자주 생긴다. 자동화는 이미 아는 것을 다시 확인할 뿐이기 때문이다. 이때 60분짜리 세션 하나가 자동화 400건보다 더 많은 것을 알려 주는 경우가 있다. 레슨 12(재현 불가능한 버그)와 모듈 4 레슨 5의 릴리즈 판정이 이 지점에서 만난다.
스크립트가 못 잡는 것의 정체
"미리 생각 못 한 것" 이라고 하면 여전히 막연하다. 실제로 어떤 종류인지 네 가지로 나눠 보면 왜 스크립트로는 안 되는지 분명해진다.
| 종류 | 예 | 왜 스크립트에 안 들어가나 |
|---|---|---|
| 순서 | 결제 중 뒤로가기 → 다시 결제 | 케이스는 보통 한 방향 흐름만 적는다 |
| 조합 | 쿠폰 + 포인트 + 부분 취소 | 조합이 너무 많아 다 적을 수 없다 |
| 타이밍 | 저장 중에 연속 클릭 | "언제" 를 케이스에 적는 관습이 없다 |
| 상태 | 오래 켜 둔 화면에서 수정 | 매번 새 상태로 시작한다고 가정한다 |
네 가지의 공통점이 있다. 케이스를 쓰는 시점에는 그런 상황이 생길 수 있다는 것 자체를 몰랐다는 것이다. 알았다면 적었을 것이다. 그래서 "케이스를 더 꼼꼼히 쓰자" 로는 해결되지 않는다 — 돌려 보면서 알아내는 과정이 따로 필요하다.
이 네 가지는 뒤 레슨의 주제와 그대로 이어진다. 순서와 타이밍은 레슨 6, 상태는 레슨 8, 조합은 숨은 변수를 다루는 레슨 5다.
채용시장에서의 위치
"탐색적 테스팅 경험" 은 QA 공고에서 가장 자주 보이는 문구 중 하나다. 다만 공고가 실제로 묻는 것은 "해 봤는가" 가 아니다. 면접에서 이 주제가 나오면 거의 항상 아래 셋 중 하나로 들어온다.
- "탐색적 테스팅과 애드혹의 차이가 뭔가요?" — 목표·시간·기록 세 가지로 답한다. 이걸 구분 못 하면 "체계 없이 일하는 사람" 으로 읽힌다
- "탐색적 테스팅 결과를 어떻게 보고하셨나요?" — 세션 노트를 설명할 수 있어야 한다. "느낌대로 눌러 봤다" 는 답은 치명적이다
- "자동화가 있는데 왜 탐색이 필요한가요?" — 위의 네 가지(순서·조합·타이밍· 상태)로 답한다. 자동화는 이미 아는 것을 다시 확인하고, 탐색은 모르는 것을 찾는다
경력이 쌓일수록 질문이 바뀐다. 주니어에게는 "할 줄 아는가" 를 묻지만, 리드 자리에서는 "팀의 탐색을 어떻게 운영했는가" 를 묻는다 — 누가 어느 영역을 몇 시간 봤는지 관리한 경험이 있는지다. 그 운영 방법이 레슨 13(짝 탐험·추정)과 세션 기반 테스트 관리다.