개념
차터란
차터(Charter)는 탐험 세션의 미션 선언문이다 — "무엇을, 어떤 자원으로, 무엇을 알아내기 위해 탐험할 것인가"를 짧게 정리한다. 시간 상자(레슨 1) 안에서 방향을 잃지 않게 해주는 나침반 역할을 한다.
표준적인 형식
Elisabeth Hendrickson이 제안한 형식이 널리 쓰인다.
Explore(탐험 대상) with(자원·도구) to discover(알아내고 싶은 것)
예: "체크아웃 흐름을, 여러 결제 수단으로 시도하며 탐험해서, 할인 계산의 오류를 찾아낸다."
이 형식이 좋은 이유는 세 가지를 강제로 채우게 만들기 때문이다 — 무엇을 볼지, 어떤 방법으로 볼지, 무엇을 알고 싶어서 보는지.
너무 막연함과 너무 구체적임 사이
| 문제 | 예시 | |
|---|---|---|
| 너무 막연함 | 방향이 없어 애드혹이 되기 쉽다 | "체크아웃 테스트하기" |
| 딱 좋음 | 방향은 있지만 구체적 절차는 안 정해짐 | "체크아웃 흐름을 여러 결제 수단으로 탐험해서 할인 계산 오류 찾기" |
| 너무 구체적 | 사실상 스크립트라 탐색적 테스팅의 장점이 사라짐 | "①카드 선택 ②쿠폰 입력 ③3만원 이상 입력 ④…" |
좋은 차터는 목적지는 정해주지만 그 안에서 가는 길은 탐험자가 실시간으로 정하게 둔다.
차터는 어디서 나오는가
차터를 처음부터 만들어내려면 막막할 수 있다. 실무에서 자주 쓰는 출발점은 다음과 같다.
- 리스크 목록(모듈 4)에서: 리스크가 높다고 판단된 영역마다 차터 하나
- 요구사항의 빈틈(모듈 2)에서: 모호하거나 누락된 부분을 "이게 실제로 어떻게 동작하는지 알아내자"는 차터로
- **호기심("만약 ~라면?")**에서: 궁금한 것 자체가 차터가 된다
- 다음 레슨에서 배울 악몽의 머리기사 게임에서
실무에서 왜 필요한가
차터가 없으면 탐험 세션이 끝난 뒤 "뭘 했는지" 설명하기 어렵고, 팀에 보고할 때도 "그냥 이것저것 봤어요"밖에 안 된다. 차터는 탐험을 계획하고, 실행하고, 보고할 수 있는 단위로 만든다. "차터 A를 70분 진행했고, 결함 2건과 질문 3가지를 발견했다"는 식으로 탐색적 테스팅도 관리 가능한 활동으로 바뀐다 — 이건 모듈 7(테스트 문서화)과 이 모듈 마지막 레슨(탐험 추정)에서 다시 쓰인다.
실습 과제
과제 1 — 차터 3개 작성하기 (15분)
"온라인 강의 사이트의 강의 시청 기능"에 대해 서로 다른 초점을 가진 차터를 3개 작성한다 (예: 재생 속도 조절, 진도율 저장, 자막 기능 등 다른 관점에서).
과제 2 — 나쁜 차터 고치기 (8분)
다음 두 차터의 문제를 지적하고 다시 쓴다.
- "회원가입 기능 테스트하기"
- "이메일 필드에 test@test.com을 입력하고, 비밀번호 필드에 Test1234!를 입력하고, 약관 체크박스를 클릭하고, 가입 버튼을 누른다."
자가 체크리스트
- 차터의 표준 형식(Explore-with-to discover)을 설명하고 직접 쓸 수 있다
- 너무 막연한 차터와 너무 구체적인(스크립트화된) 차터를 구분할 수 있다
- 차터가 나올 수 있는 네 가지 출발점(리스크, 요구사항 빈틈, 호기심, 머리기사 게임)을 안다
- 차터가 왜 탐색적 테스팅을 관리 가능하게 만드는지 설명할 수 있다
흔한 실수
- 차터를 스크립트처럼 세세하게 쓴다. 그러면 탐색적 테스팅의 핵심인 "실시간 학습과 적응"이 사라진다.
- 차터 없이 "일단 탐험부터 시작"한다. 5분만 먼저 투자해 차터를 쓰면 세션 전체의 초점이 훨씬 또렷해진다.
- 한 세션에 차터를 여러 개 욱여넣는다. 차터 하나당 세션 하나가 원칙이다. 여러 목표를 섞으면 어느 것도 충분히 못 본다.
참고 자료
- Elisabeth Hendrickson, Explore It! — 차터 형식과 작성법의 원출처
- Satisfice — Session-Based Test Management — James Bach와 Jonathan Bach가 만든, 차터를 세션 단위로 관리하는 방법론