테스트 케이스, QA 요청 받은 기획자가 처음 작성하는 법
테스트 케이스, QA 요청 받은 기획자가 처음 작성하는 법
기획자의 작업대 · 실무 가이드
프로젝트 마무리 단계에서 QA 요청을 받은 적이 있습니다. 개발된 화면을 점검하는 게 아니라, 기획한 내용이 빠짐없이 반영됐는지 확인해 달라는 요청이었습니다.
막상 시작하려니 화면을 따라가야 할지, 기획서를 따라가야 할지부터 헷갈렸습니다. 빈 엑셀 시트를 열어 두고 첫 행에 무엇을 적어야 할지 한참 고민했던 기억이 납니다.
이번 글에서는 테스트 케이스를 처음 쓰는 기획자가 어디서 출발해야 하는지, 그리고 기획서를 케이스 목록으로 바꾸는 순서를 정리해 보겠습니다.
1. 테스트 케이스란? 기획서와 무엇이 다른가
테스트 케이스(Test Case, TC)는 "이 조건에서 이렇게 하면 이런 결과가 나와야 한다"를 한 줄씩 적은 확인 목록입니다.
기획서와 다루는 대상은 같지만 질문이 다릅니다. 기획서는 "어떻게 동작해야 하는가"를 적고, 테스트 케이스는 "그렇게 동작하는지 어떻게 확인하는가"를 적습니다.
2. 화면이 아니라 기획서에서 출발해야 하는 이유
처음 TC를 쓸 때 가장 쉽게 빠지는 함정이 있습니다. 개발된 화면을 켜 놓고, 보이는 버튼과 입력창을 하나씩 따라가며 케이스를 적는 방식입니다.
이렇게 쓰면 "구현된 것"만 확인하게 됩니다. 아예 개발되지 않은 기능이나 누락된 예외 정책은 화면에 없으니, 케이스로도 잡히지 않습니다.
반대로 기획서에서 출발하면 "있어야 하는데 없는 것"까지 드러납니다. 제가 받았던 요청이 바로 이 지점이었습니다. 화면이 잘 도는지보다, 기획한 것이 다 들어갔는지를 봐야 했습니다.
다만 한계도 있습니다. 개발 도중 정책이 바뀌었는데 기획서에 반영되지 않았다면, 기준 자체가 틀어집니다. 그래서 TC를 쓰기 전에 기획서가 최신 버전인지, 구두로 합의된 변경 사항이 빠져 있지 않은지부터 확인하는 단계를 두는 편이 안전합니다.
3. 테스트 케이스 한 줄의 구성
양식은 팀마다 다르지만, 아래 항목이 있으면 처음 쓰기에는 충분합니다.
| 항목 | 설명 | 작성 예 |
|---|---|---|
| TC ID | 케이스를 부르는 고유 번호 | TC-SIGNUP-01 |
| 기획서 항목 | 이 케이스가 검증하는 기획서 조항 | 정책 3.2 비밀번호 규칙 |
| 화면·기능 | 확인 대상 위치 | 회원가입 > 비밀번호 입력 |
| 사전조건 | 테스트 전에 갖춰져야 할 상태 | 아이디 입력 완료 상태 |
| 테스트 단계 | 수행할 동작을 순서대로 | ① 비밀번호 입력 ② 다음 버튼 탭 |
| 입력값 | 실제로 넣을 값 | abc12345 |
| 기대결과 | 기획서대로라면 나와야 할 결과 | 다음 단계로 이동 |
| 실제결과 | 테스트해서 나온 결과 | (테스트 시 기입) |
| 결과 | Pass / Fail | (테스트 시 기입) |
| 비고 | 이슈 링크, 특이사항 | Fail 시 이슈 번호 |
여기서 가장 신경 쓸 칸은 기대결과입니다. "정상 동작"처럼 쓰면 확인하는 사람마다 판단이 달라집니다. "'비밀번호는 8자 이상 입력해 주세요' 안내 문구가 입력창 아래에 노출"처럼, 눈으로 보고 판단할 수 있는 결과로 적어야 합니다.
4. 기획서에서 케이스 뽑는 순서
기획서를 펼쳐 놓고 아래 네 단계 순서로 케이스를 뽑으면 빠지는 부분이 줄어듭니다.
- 정상 흐름: 사용자가 의도대로 진행했을 때 끝까지 가는지
- 예외 흐름: 잘못 입력하거나 중간에 이탈했을 때 기획서대로 처리되는지
- 경계값: 규칙의 기준선 바로 안쪽과 바깥쪽에서 결과가 갈리는지
- 권한·상태별: 비회원/회원, 신규/기존처럼 사용자 상태에 따라 달라지는지
사례: 비밀번호 규칙 하나로 케이스 뽑아 보기
기획서에 아래 정책이 있다고 가정해 보겠습니다.
8자 이상 20자 이하 / 영문·숫자·특수문자 중 2종 이상 조합 / 아이디와 같은 값 사용 불가 / 비밀번호 확인란과 일치해야 함
정책 문장이 네 개뿐인데, 케이스로 풀면 이렇게 늘어납니다.
| TC ID | 구분 | 입력값 | 기대결과 |
|---|---|---|---|
| TC-01 | 정상 | abc12345 (8자, 2종) | 다음 단계로 이동 |
| TC-02 | 경계값 | abc1234 (7자) | "8자 이상 입력해 주세요" 문구 노출, 다음 버튼 비활성 |
| TC-03 | 경계값 | 20자 조합 값 | 다음 단계로 이동 |
| TC-04 | 경계값 | 21자 조합 값 | 21번째 글자 입력 차단 또는 안내 문구 노출 |
| TC-05 | 예외 | abcdefgh (영문만) | "2종 이상 조합" 안내 문구 노출 |
| TC-06 | 예외 | 아이디와 같은 값 | "아이디와 다르게 설정해 주세요" 문구 노출 |
| TC-07 | 예외 | 확인란에 다른 값 입력 | "비밀번호가 일치하지 않습니다" 문구 노출 |
TC-04를 쓰다 보면 한 가지 질문이 생깁니다. 21자를 입력하면 막아야 할지, 입력은 받고 안내만 할지 기획서에 없다는 사실입니다. 이렇게 기대결과를 쓰다가 막히는 지점이 곧 기획서의 빈칸입니다. TC 작성이 기획서 검수 역할까지 겸하는 이유입니다.
정책을 조건 단위로 정리해 두면 이 단계가 훨씬 수월해집니다. 관련 내용은 정책서가 필요한 이유, 피그마만으론 안 되는 것에서 다뤘습니다.
5. 실무 팁 3가지
팁1. 기획서 항목마다 TC ID를 연결해 둔다
| 기획서 항목 | 연결된 TC | 상태 |
|---|---|---|
| 3.2 비밀번호 길이 | TC-01~04 | 작성 완료 |
| 3.2 조합 규칙 | TC-05 | 작성 완료 |
| 3.3 비밀번호 재설정 | - | 미작성 |
팁2. 한 케이스에서는 한 가지만 확인한다
팁3. 우선순위를 붙여 일정 변수에 대비한다
6. 마무리
- 기획 반영 QA라면 개발된 화면이 아니라 기획서에서 출발해야 누락까지 잡을 수 있습니다.
- 정상 흐름 → 예외 흐름 → 경계값 → 권한·상태 순서로 뽑고, 기대결과는 눈에 보이는 결과로 씁니다.
- 기획서 항목과 TC ID를 연결해 두면, 확인이 빠진 조항이 한눈에 드러납니다.
다음에 QA 요청을 받으면 화면보다 기획서를 먼저 열어 보세요. 가장 짧은 정책 하나를 골라 케이스 5개를 뽑아 보는 것으로 시작해도 충분합니다.
여러분 팀은 테스트 케이스를 누가, 어떤 도구로 쓰고 계신가요. Fail 케이스를 개발자에게 이슈로 넘기는 방법이 궁금하다면 Jira 기획자 가이드, 8편을 순서대로 읽는 법에서 요청 작성법 글부터 보시면 좋습니다.