차터(Charter) 작성법 — 좋은 차터의 조건

개념

차터란

차터(Charter)는 탐험 세션의 미션 선언문이다 — 한 문장짜리 목표이고, 이 레슨에서 배울 것의 전부다. 앞 레슨에서 "탐색적 테스팅은 애드혹과 달리 목표가 있다" 고 했는데, 그 목표를 적은 문장이 차터다.

정확히는 "무엇을, 어떤 자원으로, 무엇을 알아내기 위해 탐험할 것인가" 를 짧게 정리한 것이다. 시간 상자(레슨 1) 안에서 방향을 잃지 않게 해 주는 나침반 역할을 한다.

비유로 보면 더 분명하다. 레슨 1 의 탐험 비유에서 "오늘 오전은 구시가지를 본다" 에 해당하는 것이 차터다. 어느 골목으로 들어갈지는 안 정했지만 어느 동네에 있을지는 정했다. 이 한 문장이 없으면 발이 가는 대로 걷게 되고, 그건 애드혹이다.

차터는 길어야 두 줄이다. 길어지면 그건 차터가 아니라 계획서다.

표준적인 형식

Elisabeth Hendrickson이 제안한 형식이 널리 쓰인다.

Explore(탐험 대상) with(자원·도구) to discover(알아내고 싶은 것)

예: "체크아웃 흐름을, 여러 결제 수단으로 시도하며 탐험해서, 할인 계산의 오류를 찾아낸다."

이 형식이 좋은 이유는 세 가지를 강제로 채우게 만들기 때문이다 — 무엇을 볼지, 어떤 방법으로 볼지, 무엇을 알고 싶어서 보는지.

너무 막연함과 너무 구체적임 사이

좋은 차터는 목적지는 정해주지만 그 안에서 가는 길은 탐험자가 실시간으로 정하게 둔다.

세 칸을 하나씩 뜯어보기

형식만 외우면 칸을 억지로 채우게 된다. 각 칸이 실제로 무엇을 막아 주는지 알면 쓰기가 쉬워진다.

탐험 대상 — "어디까지가 내 영역인가"

범위를 긋는 칸이다. "체크아웃 흐름" 이라고 적으면 장바구니 담기는 범위 밖이 된다. 탐험 중에 "이것도 이상한데" 가 나오면 적어만 두고 넘어간다 — 그것이 다음 차터가 된다. 이 선이 없으면 한 세션이 끝없이 번진다.

자원·도구 — "어떤 조건으로 볼 것인가"

가장 많이 비워 두는 칸이고, 비우면 탐험이 얕아진다. 여기 적을 수 있는 것은 생각보다 많다.

이 칸이 탐험의 깊이를 정한다. "여러 결제 수단으로" 를 적은 사람과 안 적은 사람은 같은 60분을 전혀 다르게 쓴다.

알아내고 싶은 것 — "무엇을 들고 나올 것인가"

세션이 끝났을 때 답할 수 있어야 하는 질문이다. "할인 계산의 오류를 찾는다" 라고 적었으면, 세션 끝에 "오류 2건 찾았다" 또는 "60분간 찾지 못했다" 중 하나로 답해야 한다. 못 찾았다도 답이다 — 그 영역을 60분 봤다는 정보가 남는다.

이 칸을 "체크아웃이 잘 되는지 확인" 처럼 적으면 답할 수 없는 질문이 된다. 무엇이 "잘 되는" 것인지 안 정했기 때문이다.

차터는 어디서 나오는가

차터를 처음부터 만들어내려면 막막할 수 있다. 실무에서 자주 쓰는 출발점은 다음과 같다.

• 리스크 목록(모듈 4)에서: 리스크가 높다고 판단된 영역마다 차터 하나
• 요구사항의 빈틈(모듈 2)에서: 모호하거나 누락된 부분을 "이게 실제로 어떻게 동작하는지 알아내자"는 차터로
• 호기심("만약 ~라면?") 에서: 궁금한 것 자체가 차터가 된다
• 다음 레슨에서 배울 악몽의 머리기사 게임에서

좋은 차터와 나쁜 차터 — 실제 예시

표로 본 기준을 실제 문장에 적용해 보자. 같은 기능을 두고 쓴 차터들이다.

세 번째가 특히 흔한 실수다. "5회 틀리면 잠긴다" 를 이미 알고 쓴 문장이라 확인만 하게 된다. 탐험의 목적은 모르는 것을 알아내는 것이므로, 아는 것을 확인하려면 케이스를 쓰는 편이 낫다.

네 번째도 자주 나온다. 목적 칸에 "버그를 찾는다" 를 적으면 아무것도 좁혀지지 않는다. 어떤 종류의 버그인지 적어야 그쪽으로 손이 간다.

차터 하나는 얼마나 커야 하나

경험적으로 60~90분에 끝나는 크기가 좋다. 너무 크면 시간 안에 다 못 봐서 "대충 훑기" 가 되고, 너무 작으면 20분 만에 할 게 없어진다.

크기를 가늠하는 간단한 방법이 있다. 차터를 읽고 "첫 10분에 뭘 할지"가 바로 떠오르는가를 본다.

• 안 떠오르면 너무 크다. "결제 전체를 탐험" 같은 경우다. 쪼갠다
• 10분이면 다 할 것 같으면 너무 작다. 자원 칸을 늘려 깊이를 더한다

쪼갤 때는 기능이 아니라 관점으로 나누는 편이 낫다. "결제" 를 "카드 결제 / 간편 결제 / 포인트 결제" 로 나누는 것보다, "결제 금액 계산 / 결제 실패 복구 / 결제 수단 전환" 으로 나누면 각 세션이 서로 다른 종류의 결함을 겨냥하게 된다.

차터를 함께 쓰면 생기는 일

차터는 혼자 써도 되지만, 30분만 함께 쓰면 결과가 달라진다. 개발자와 기획자를 한자리에 앉혀 놓고 "이 기능에서 뭐가 제일 걱정되세요" 를 물으면, QA 혼자서는 절대 못 떠올릴 문장이 나온다.

• 개발자가 아는 것 — "거기 로직이 두 군데에 나뉘어 있어서 한쪽만 고쳤어요", "그 값은 캐시에 남아요". 코드를 아는 사람만 아는 약한 고리다
• 기획자가 아는 것 — "그 정책이 지난달에 바뀌었어요", "운영팀이 수동으로 고쳐 주고 있어요". 문서에 없는 실제 운영 사정이다
• 고객 지원이 아는 것 — "그 문의가 매주 들어와요". 사용자가 실제로 겪는 문제다

세 쪽에서 나온 말이 각각 차터 한 줄이 된다. 그리고 이 자리에는 부수 효과가 하나 더 있다 — 아직 코드가 없는 기능이라면 그 대화 자체가 결함을 막는다. "그러고 보니 그 경우는 생각 안 했네요" 가 나오면, 모듈 1에서 본 "맨 앞에서 잡으면 싸다" 가 실제로 일어난 것이다.

실무에서 왜 필요한가

차터가 없으면 탐험 세션이 끝난 뒤 "뭘 했는지" 설명하기 어렵고, 팀에 보고할 때도 "그냥 이것저것 봤어요"밖에 안 된다. 그리고 그 한마디 때문에 탐색적 테스팅 전체가 "놀았다" 로 읽히는 일이 실제로 벌어진다. 같은 60분을 쓰고도 차터가 있으면 "이 영역을 이 조건으로 봤고 이것을 알아냈다" 가 되고, 없으면 설명할 말이 남지 않는다. 차터는 탐험을 계획하고, 실행하고, 보고할 수 있는 단위로 만든다. "차터 A를 70분 진행했고, 결함 2건과 질문 3가지를 발견했다"는 식으로 탐색적 테스팅도 관리 가능한 활동으로 바뀐다 — 이건 모듈 7(테스트 문서화)과 이 모듈 마지막 레슨(탐험 추정)에서 다시 쓰인다.

같은 기능, 깊이가 다른 세 차터

차터의 자원 칸이 깊이를 정한다고 했다. 같은 대상을 두고 자원만 바꿔 보면 세션이 얼마나 달라지는지 보인다. 비밀번호 변경 기능을 예로 든다.

얕은 차터

"비밀번호 변경을 탐험해서, 오류가 있는지 찾는다"

자원이 비어 있다. 아마 새 비밀번호를 한두 개 넣어 보고 "잘 되네" 로 끝난다. 20분이면 할 게 없어진다.

보통 차터

"비밀번호 변경을, 규칙에 어긋나는 값들로 시도하며 탐험해서, 검증이 빠진 조합을 찾는다"

자원이 생기니 할 일이 늘었다. 짧은 값, 공백만, 아주 긴 값, 특수문자, 한글, 현재 비밀번호와 같은 값. 60분이 채워진다.

깊은 차터

"비밀번호 변경을, 변경 직후의 기존 로그인 세션·저장된 자동 로그인·다른 기기의 접속 상태를 함께 보며 탐험해서, 변경이 어디까지 전파되는지 알아낸다"

여기서부터 다른 종류의 결함이 나온다. 비밀번호를 바꿨는데 다른 기기에서 계속 로그인돼 있다면 그건 보안 문제다. 화면만 보면 절대 안 보이고, 세 번째 차터를 쓴 사람만 찾는다.

세 문장의 차이는 아는 만큼이다. 비밀번호 변경이 세션에 영향을 준다는 것을 알아야 세 번째를 쓸 수 있다. 그래서 차터 쓰기 실력은 도메인·기술 지식과 함께 자란다 — 레슨 1에서 말한 "경력이 쌓일수록 잘 되는 활동" 이 여기서도 보인다.

막혔을 때 쓰는 요령이 하나 있다. 자원 칸에 넣을 것이 안 떠오르면 "이 동작이 바꾸는 것이 또 뭐가 있지?" 를 물어본다. 비밀번호 변경은 세션을, 주문 취소는 쿠폰과 재고를, 탈퇴는 작성한 글과 댓글을 바꾼다. 그 "또" 가 거의 항상 깊은 차터의 자원이 된다.

차터 모음 — 쇼핑몰 하나를 예로

실제로 어떤 문장들이 나오는지 한 서비스에 대해 모아 보면 감이 잡힌다. 관점별로 나눈 것에 주목한다.

이 일곱 줄이 쇼핑몰 하나의 탐험 계획 전체가 될 수 있다. 각각 60~90분이면 대략 사람 하나의 사나흘 분량이다.

여기서 하나 눈여겨볼 것이 있다. 일곱 관점이 거의 모든 서비스에 그대로 적용된다. 계산·상태·권한·입력·중단·환경·시간은 도메인을 가리지 않는다. 처음 맡은 제품이라 뭘 봐야 할지 모르겠다면, 이 일곱 칸에 그 제품의 이름을 넣어 보는 것부터 시작하면 된다.

흔히 쓰는 차터 출발점 — 열 문장 틀

매번 빈 종이에서 시작할 필요는 없다. 아래 열 개 틀에 제품 이름을 넣으면 대부분의 상황에서 쓸 만한 차터가 나온다.

1. 경계 — "~를, 허용 범위의 맨 끝 값들로 시도하며 탐험해서, 한 칸 차이로 갈리는 지점을 찾는다"
2. 빈 값 — "~를, 비어 있거나 아직 안 정해진 상태로 탐험해서, 빈칸을 가정하지 않은 화면을 찾는다"
3. 중복 — "~를, 같은 동작을 빠르게 두 번 하며 탐험해서, 두 번 처리되는 지점을 찾는다"
4. 되돌리기 — "~를, 하고 나서 취소·수정·삭제하며 탐험해서, 되돌려지지 않는 것을 찾는다"
5. 권한 — "~를, 권한이 다른 계정으로 시도하며 탐험해서, 보이면 안 되는 것이 보이는지 알아낸다"
6. 끊김 — "~를, 중간에 통신을 끊거나 창을 닫으며 탐험해서, 반쯤 처리된 상태가 남는지 찾는다"
7. 시간 — "~를, 마감·만료·자정 경계 시각에 탐험해서, 날짜 계산이 틀어지는지 알아낸다"
8. 양 — "~를, 아주 많은 건수와 아주 긴 글자로 탐험해서, 느려지거나 잘리는 지점을 찾는다"
9. 연결 — "~를, 다른 기능과 번갈아 쓰며 탐험해서, 한쪽이 다른 쪽을 망가뜨리는지 알아낸다"
10. 환경 — "~를, 작은 화면·느린 통신·다른 브라우저에서 탐험해서, 조건에 따라 달라지는 동작을 찾는다"

이 열 개는 암기할 것이 아니라 막혔을 때 꺼내 보는 목록이다. 레슨 14의 휴리스틱 치트시트가 이 발상을 모듈 전체 범위로 넓힌 것이다.

한 가지 주의할 것이 있다. 열 개를 전부 쓰지 않는다. 제품마다 위험한 축이 다르다. 쇼핑몰이면 4·7번(되돌리기·시간)이 중요하고, 사내 관리 시스템이면 5번(권한)이, 콘텐츠 서비스면 8·10번(양·환경)이 중요하다. 고르는 것이 리스크 판단이고, 그 근거는 모듈 4에서 배운 것 그대로다.

차터가 안 써질 때

"뭘 알아내고 싶은지" 가 안 떠오를 때가 있다. 제품을 아직 모르거나, 기능이 너무 새로워서다. 그럴 때 쓰는 방법이 둘 있다.

하나, 정찰 차터를 먼저 돌린다. 목적 칸을 "결함 찾기" 가 아니라 "구조 파악" 으로 둔다.

"주문 관리 화면을, 메뉴를 하나씩 눌러 보며 탐험해서, 어떤 기능들이 있고 무엇이 서로 연결돼 있는지 지도를 만든다"

이 세션의 산출은 결함이 아니라 다음 차터 목록이다. 레거시 시스템을 맡았을 때 쓰는 방법이고, 레슨 11에서 자세히 다룬다.

둘, 반대로 물어본다. "무엇을 찾을까" 가 안 떠오르면 "무엇이 터지면 가장 큰일인가" 를 묻는다. 그 답이 거의 바로 차터가 된다. 이것을 게임처럼 만든 것이 다음 레슨의 악몽의 머리기사 게임이다.

차터는 어디에 적어 두나

도구는 중요하지 않다. 표 하나면 된다. 다만 세 가지는 같이 적어 둔다.

"안 함" 상태가 있다는 것이 중요하다. 버린 차터를 지우면 안 본 영역이 기록에서 사라진다. 지우는 대신 "이번 릴리즈에서는 안 함" 으로 남기면, 다음 릴리즈의 후보 목록이 되기도 한다.

테스트 관리 도구를 쓰는 조직이라면 차터를 케이스가 아니라 별도 항목으로 둔다. 케이스 목록에 섞으면 "케이스 200건 중 7건이 차터" 같은 이상한 통계가 나온다. 도구별 구체적인 운영은 모듈 22에서 다룬다.

차터에서 케이스로 — 언제 넘기나

레슨 1에서 "탐험에서 찾은 것은 케이스로 고정한다" 고 했다. 그 기준을 좀 더 분명히 해 두자. 모든 발견을 케이스로 만들지는 않는다.

두 번째 줄이 실무에서 가장 자주 틀린다. 안 고치기로 한 결함의 케이스를 만들면 그 케이스는 영원히 실패한다. 자동화에 넣으면 매일 빨간불이 켜지고, 몇 주 뒤엔 아무도 그 빨간불을 안 본다. 모듈 14에서 다루는 "믿을 수 없는 실패" 가 이렇게 쌓인다.

차터 목록이 곧 테스트 계획이 된다

차터 하나는 세션 하나지만, 차터 목록은 그 자체로 계획서다. 릴리즈 하나를 앞두고 차터를 10개 적어 두면 아래가 한꺼번에 정해진다.

• 범위 — 적힌 10개가 볼 영역이고, 안 적힌 것은 안 볼 영역이다
• 일정 — 세션당 6090분이므로 10개면 대략 23일
• 배분 — 도메인을 아는 사람에게 어느 차터를 줄지
• 진척 — 완료 3 / 진행 1 / 대기 6 으로 매일 말할 수 있다
• 잔여 위험 — 시간이 모자라 못 한 차터가 곧 "안 본 영역" 목록이다

마지막 줄이 중요하다. 모듈 4 레슨 5의 릴리즈 판정에서 "무엇을 안 봤는가" 를 물을 때, 남은 차터 목록이 그대로 답이 된다. "시간이 없어서 결제 수단 전환과 해외 카드는 못 봤습니다" 라고 말할 수 있는 근거다.

차터 하나를 두 사람이 받으면

같은 차터를 두 사람이 따로 탐험하면 겹치는 부분이 생각보다 적다. 사람마다 떠올리는 상황이 다르기 때문이다. 그래서 중요한 영역은 일부러 두 명에게 같은 차터를 주기도 한다.

반대로 한 차터를 둘이 함께 탐험하는 방식도 있다 — 한 사람이 조작하고 한 사람이 관찰하며 질문을 던진다. 혼자 할 때보다 "어? 방금 뭐였지" 를 놓치는 일이 줄어든다. 이 방식이 레슨 13의 짝 탐험이다.

채용시장에서의 위치

차터는 면접에서 "탐색적 테스팅을 체계적으로 했는가" 를 가르는 증거로 쓰인다. "탐색적 테스팅 경험이 있다" 는 말에 면접관이 이어 묻는 질문이 대개 이것이다.

• "세션을 어떻게 나누셨나요?" — 차터 단위로 나눴다고 답할 수 있어야 한다
• "무엇을 봤는지 어떻게 보고하셨나요?" — 차터별 결과로 보고했다고 답한다
• "시간이 모자라면 어떻게 하셨나요?" — 남은 차터를 잔여 위험으로 보고했다고 답한다. 이 답이 나오면 관리까지 할 줄 아는 사람으로 읽힌다

차터를 쓸 줄 안다는 것은 결국 자기 일을 남에게 설명할 수 있다는 뜻이고, 그게 주니어와 그 위를 가르는 지점이다.

실습 과제

과제 1 — 차터 3개 작성하기 (15분)

"온라인 강의 사이트의 강의 시청 기능"에 대해 서로 다른 초점을 가진 차터를 3개 작성한다 (예: 재생 속도 조절, 진도율 저장, 자막 기능 등 다른 관점에서).

과제 2 — 나쁜 차터 고치기 (8분)

다음 두 차터의 문제를 지적하고 다시 쓴다.

1. "회원가입 기능 테스트하기"
2. "이메일 필드에 test@test.com을 입력하고, 비밀번호 필드에 Test1234!를 입력하고, 약관 체크박스를 클릭하고, 가입 버튼을 누른다."

과제 3 — 차터 목록으로 계획 세우기 (15분)

자주 쓰는 서비스 하나를 골라, 릴리즈 하나를 가정하고 차터를 6개 적는다. 그리고 아래 두 가지를 덧붙인다.

• 각 차터에 우선순위를 매긴다(높음·보통·낮음)
• 시간이 절반밖에 없다면 어느 3개를 버릴지 정하고, 그 이유를 한 줄씩 적는다

자가 체크리스트

• 차터의 표준 형식(Explore-with-to discover)을 설명하고 직접 쓸 수 있다
• 너무 막연한 차터와 너무 구체적인(스크립트화된) 차터를 구분할 수 있다
• 차터가 나올 수 있는 네 가지 출발점(리스크, 요구사항 빈틈, 호기심, 머리기사 게임)을 안다
• 차터가 왜 탐색적 테스팅을 관리 가능하게 만드는지 설명할 수 있다
• 세 칸(대상·자원·목적)이 각각 무엇을 막아 주는지 말할 수 있다
• 차터 크기를 "첫 10분에 뭘 할지 떠오르는가" 로 가늠할 수 있다
• 차터를 쪼갤 때 기능이 아니라 관점으로 나눌 수 있다
• 남은 차터 목록을 잔여 위험으로 보고할 수 있다

흔한 실수

• 차터를 스크립트처럼 세세하게 쓴다. 그러면 탐색적 테스팅의 핵심인 "실시간 학습과 적응"이 사라진다.
• 차터 없이 "일단 탐험부터 시작"한다. 5분만 먼저 투자해 차터를 쓰면 세션 전체의 초점이 훨씬 또렷해진다.
• 한 세션에 차터를 여러 개 욱여넣는다. 차터 하나당 세션 하나가 원칙이다. 여러 목표를 섞으면 어느 것도 충분히 못 본다.
• 답을 이미 알고 차터를 쓴다. "5회 틀리면 잠기는지 확인한다" 는 케이스다. 아는 것을 확인하려면 케이스를, 모르는 것을 알아내려면 차터를 쓴다.
• 목적 칸에 "버그를 찾는다" 를 적는다. 모든 차터에 해당하는 말이라 아무것도 좁혀지지 않는다. 어떤 종류의 버그인지 적어야 손이 그쪽으로 간다.
• 자원 칸을 비워 둔다. 가장 자주 비는 칸이고, 비면 탐험이 얕아진다. 데이터·계정·환경·도구 중 최소 하나는 적는다.
• 범위 밖 발견을 그 자리에서 쫓아간다. 적어만 두고 넘어가야 세션이 끝난다. 쫓아간 것은 다음 차터로 만든다.
• 끝난 차터만 보고하고 못 한 차터는 지운다. 못 한 목록이 곧 안 본 영역이고, 릴리즈 판정에 필요한 정보다.

참고 자료

• 이 커리큘럼 안: 레슨 1(시간 상자·세션 노트), 레슨 3(악몽의 머리기사 게임 — 차터를 만드는 또 다른 출발점), 레슨 11(정찰 세션), 레슨 13(짝 탐험·추정)
• 이 커리큘럼 안: 모듈 4 레슨 2(리스크 기반 테스트 — 차터 우선순위의 근거), 모듈 4 레슨 5(릴리즈 판정 — 남은 차터가 잔여 위험이 되는 자리)
• Elisabeth Hendrickson, Explore It! — 차터 형식과 작성법의 원출처
• Satisfice — Session-Based Test Management — James Bach와 Jonathan Bach가 만든, 차터를 세션 단위로 관리하는 방법론