개념
앞의 다섯 레슨이 계속 가리켜 온 것이 이 레슨이다 — Part 3의 실물. 외부에서 요구받는 것이 대부분 문서이므로(레슨 2), QA가 가장 많이 펼치는 부분이기도 하다.
건축 도면 묶음을 떠올리면 관계가 잡힌다. 평면도·입면도·구조도는 따로 그려지지만 같은 건물이다. 그래서 평면도의 기둥 위치가 구조도와 다르면 어느 하나가 틀린 것이고, 그 불일치가 감사에서 지적되는 지점이다.
테스트 문서도 같다. 이 레슨에서 볼 것은 각 문서의 항목과 더불어 문서들이 서로 맞물리는 방식이다.
사례로 따라가기 — "쿠폰 적용" 기능
지금까지 배운 조직·관리·동적 프로세스가 실제로 어떤 문서로 남는지, 하나의 가상 사례("장바구니에 쿠폰을 적용하는 기능")로 끝까지 따라가 본다.
문서 1 — 테스트 계획서(Test Plan)
레슨 4(관리 프로세스)의 계획 단계 산출물. 모듈 4(레슨 1)에서 이미 작성해본 형식과 크게 다르지 않다.
표준이 요구하는 항목은 예시보다 많다. 실무에서 쓸 때는 목록으로 두고 빈칸을 채우는 방식이 안전하다.
| 항목 | 내용 | 자주 빠지나 |
|---|---|---|
| 문서 식별 | 제목·버전·날짜·작성자·승인자 | — |
| 테스트 대상 | 무엇을 테스트하나(버전 포함) | — |
| 범위 | 포함과 제외를 모두 | 제외가 빠진다 |
| 참조 문서 | 요구사항·설계 문서 | 자주 빠진다 |
| 테스트 수준·유형 | 어느 수준에서 무엇을 | — |
| 리스크와 대응 | 위험 항목과 완화 방법 | 대응이 빠진다 |
| 접근 방법 | 적용할 설계 기법(Part 4 용어) | 자주 빠진다 |
| 산출물 | 어떤 문서를 남기나 | 거의 빠진다 |
| 환경 요구 | 필요한 환경·데이터·도구 | 자주 빠진다 |
| 일정·공수 | 기간과 투입 | — |
| 역할·책임 | 누가 무엇을 | 빠진다 |
| 진입·종료 조건 | 시작 조건과 완료 기준 | 가장 많이 지적된다 |
| 중단·재개 기준 | 어떤 상황에서 멈추나 | 거의 빠진다 |
마지막 두 줄이 반려의 단골이다(레슨 1의 사례). 종료 조건은 모듈 4 레슨 4에서 배운 그것이고, 중단·재개 기준은 생각해 본 적이 없는 팀이 많다.
중단 기준은 어렵지 않다 — "환경이 하루 이상 불가하면 중단하고 보고", "차단 결함으로 50% 이상 실행 불가 시 중단" 같은 문장이면 된다. 이것이 있으면 모듈 8 레슨 4의 통제 단계에서 판단이 자동으로 열린다.
재단한 항목을 표시하는 방법
레슨 1의 테일러링을 문서에 적용하는 모습이다. 해당 없는 항목을 비우지 않고 사유를 적는다.
9. 환경 요구
해당 없음 — 기존 스테이징 환경을 그대로 사용 (환경 변경 없음)
13. 중단·재개 기준
- 중단: 스테이징 환경이 4시간 이상 사용 불가한 경우
- 재개: 환경 복구 확인 후, 영향받은 케이스를 재실행한 뒤 진행9번처럼 적어 두면 누락이 아니라 판단이고, 심사자가 되묻지 않는다.
- 테스트 대상: 장바구니 쿠폰 적용 기능
- 범위: 쿠폰 코드 입력, 할인 계산, 적용 취소
- 리스크: 할인 금액 계산 오류(재무 영향 큼) → 리스크 기반으로 집중 테스트
- 일정: 기능 완료 후 3일
- 종료 기준: 심각도 높음 결함 0건, 계획된 케이스 95% 이상 실행문서 2 — 테스트 설계 명세(Test Design Specification)
레슨 5(동적 프로세스)의 설계 단계 산출물. 어떤 테스트 조건이 필요한지 정리한다.
- 조건 1: 유효한 쿠폰 코드 입력 시 할인이 정확히 계산되는가
- 조건 2: 만료된 쿠폰 코드 입력 시 적절한 오류가 표시되는가
- 조건 3: 이미 사용한 쿠폰 재사용 시도 시 거부되는가
- 조건 4: 쿠폰 적용 후 취소 시 원래 금액으로 복원되는가조건에는 출처와 우선순위를 함께 붙인다. 이 두 열이 추적표와 실행 순서의 근거가 된다(레슨 5).
| 조건 | 출처 | 우선순위 |
|---|---|---|
| 1. 유효 쿠폰 할인 계산 | 요구 REQ-014 | 높음(금액) |
| 2. 만료 쿠폰 오류 표시 | 요구 REQ-015 | 중간 |
| 3. 재사용 거부 | 리스크(중복 사용 손실) | 높음 |
| 4. 취소 시 금액 복원 | 경험(되돌리는 흐름) | 높음 |
3번과 4번의 출처가 요구사항이 아닌 것에 주목할 만하다. 문서에 없지만 실제 위험이 있는 조건이고, 그것을 출처와 함께 적어 두면 나중에 "왜 이걸 봤나" 를 설명할 수 있다(레슨 5의 세 출처).
문서 3 — 테스트 케이스 명세(Test Case Specification)
설계 명세의 각 조건을 구체적인 입력값과 기대 결과로 구체화한다 — 모듈 3에서 배운 테스트 케이스 작성 방식 그대로다.
케이스 ID: TC-CPN-001
조건: 유효한 쿠폰 코드 입력 시 할인이 정확히 계산되는가
사전조건: 장바구니에 상품 총액 10,000원 담긴 상태
절차: "SAVE10"(10% 할인 쿠폰) 입력 후 "적용" 클릭
기대 결과: 최종 금액이 9,000원으로 표시됨케이스 명세에서 빠지면 재사용이 안 되는 항목이 둘 있다.
| 항목 | 왜 필요한가 |
|---|---|
| 식별자(ID) | 추적표·결함·실행 기록이 이것으로 연결된다 |
| 사전조건 | 없으면 쓴 사람만 실행할 수 있다(모듈 7 레슨 1) |
ID 규칙은 단순할수록 좋다. TC-CPN-001 처럼 영역 약어 + 번호면
충분하고, 중요한 것은 한 번 부여한 ID를 바꾸지 않는 것이다. 바꾸면
결함·보고서에 적힌 참조가 전부 끊긴다.
문서 3.5 — 실행 기록과 인시던트 보고
예시에서 건너뛰기 쉬운데, 표준은 실행 기록과 인시던트 보고도 산출물로 본다(레슨 5의 3·4단계).
실행 기록 (런 ID: RUN-CPN-2026-10-02)
TC-CPN-001 Pass
TC-CPN-002 Pass
TC-CPN-003 Fail → INC-031
TC-CPN-004 Blocked (BUG-540 로그인 결함)
환경: 스테이징 / 빌드 v2.14.3 / 실행자·실행 시각 기록
인시던트 보고 (INC-031)
현상: 사용 완료된 쿠폰이 재사용 시 다시 적용됨
재현: 5/5
원인 분류: 제품 결함 → BUG-551 로 등록
영향: 쿠폰 중복 사용 가능. 금전 손실원인 분류 줄이 레슨 5의 삼분법이 문서에 나타나는 자리다. 이것이 적혀 있으면 완료 보고서에서 제품 결함만 골라 세는 것이 가능해지고, 모듈 6 레슨 5의 지표가 거짓이 되지 않는다.
Blocked 줄도 중요하다. 차단 사유에 결함 번호를 적어 두면 그 결함의 우선순위를 올릴 근거가 된다(모듈 8 레슨 4의 통제).
문서 3.7 — 테스트 상태 보고서
관리 프로세스의 모니터링 단계 산출물이다(레슨 4). 주 1회 한 장이면 된다.
테스트 상태 보고 (2026-09-29 주차)
진척 실행 150/240 (63%) · 계획 대비 -12%
품질 미해결 S1 1건, S2 3건 · 재오픈율 9%
차단 30건 (BUG-540 로그인 — 우선 처리 요청)
위험 결제 영역 차터 2개 미착수. 이대로면 미확인으로 남음
요청 BUG-540 당일 처리 / 저위험 40건 제외 여부 판단 필요"위험" 과 "요청" 두 줄이 이 문서를 쓸모 있게 만든다. 숫자만 있는 보고는 읽히지 않고, 판단이 필요한 것을 적으면 그 주에 결정이 난다.
문서 4 — 테스트 완료 보고서(Test Completion Report)
레슨 4의 완료 단계 산출물이자, 모듈 6(레슨 2)에서 배운 결함 리포트 작성 원칙이 요약 형태로 다시 등장하는 지점이다.
- 실행 결과: 계획된 12개 케이스 중 12개 실행(커버리지 100%)
- 결함 현황: 발견 3건(심각도 높음 0건, 중간 2건, 낮음 1건) — 모두 종결
- 잔존 리스크: 없음(모든 심각도 높음 결함 해결 확인)
- 배운 점: 쿠폰 만료 시각 처리에서 시간대(timezone) 관련 결함이 반복
발견됨 — 다음 프로젝트의 조직 테스트 전략(레슨 3)에 "날짜/시간
경계값은 항상 시간대를 명시해 테스트한다"는 항목 추가 제안완료 보고서에 반드시 들어가야 하는 다섯 줄이 있다. 예시에는 넷이 있고 하나가 빠져 있다.
| 항목 | 예시에 있나 |
|---|---|
| 실행 결과 요약 | ✓ |
| 결함 현황 | ✓ |
| 잔존 리스크 | ✓ |
| 배운 점 | ✓ |
| 못 한 것(미실시·미확인 영역) | 빠져 있다 |
예시는 "커버리지 100%" 라서 못 한 것이 없는 이상적인 경우인데, 실무에서 그런 릴리즈는 거의 없다. 그래서 보고서에는 이런 줄이 들어간다.
- 미실시: 다국어 환경(사유: 범위 제외 합의), 저사양 기기(사유: 기기 미확보)
- 미확인: 쿠폰 수천 건 동시 사용 시 동작 (사유: 부하 환경 없음)
→ 운영 배포 후 쿠폰 사용 실패율을 2주간 감시이 두 줄이 보고서의 신뢰를 결정한다(모듈 6 레슨 5·모듈 5 레슨 13과 같은 원칙). 그리고 감사에서 묻는 "일관성"(레슨 1)이 바로 여기서 확인된다 — 계획서에 쓴 범위와 실제 실행이 다르면, 그 차이가 이 줄에 설명되어 있어야 한다.
추적표 — 별도 문서가 아니라 연결
레슨 1의 사례에서 반려 사유 중 하나가 "요구사항과 케이스의 추적표가 없다" 였다. 실물은 단순하다.
| 요구 | 조건 | 케이스 | 실행 결과 | 결함 |
|---|---|---|---|---|
| REQ-014 | 조건 1 | TC-CPN-001·002 | Pass·Pass | — |
| REQ-015 | 조건 2 | TC-CPN-003 | Fail | BUG-551 |
| (없음) | 조건 3 | TC-CPN-004 | Blocked | — |
| REQ-018 | (없음) | (없음) | — | — |
아래 두 줄이 이 표를 만드는 이유다.
- 조건 3에 요구가 없다 — 리스크·경험에서 나온 조건이다. 정상이지만 출처를 적어 둬야 한다
- REQ-018에 케이스가 없다 — 검증되지 않은 요구다. 이것이 요구사항 커버리지의 공백이고(모듈 6 레슨 5), 실행률 100%로는 절대 안 보인다
이 표는 손으로 만들지 않는다. 테스트 관리 도구에 요구 링크를 걸어 두면 뽑아낼 수 있고(모듈 7 레슨 1), 레슨 2 사례에서 "도구에 있었는데 제출 형식으로 뽑지 않아" 지적된 것이 바로 이 표다.
문서를 줄이는 법
작은 조직이 이 문서를 전부 따로 만들면 일이 안 된다. 합칠 수 있는 조합이 정해져 있다.
| 합치기 | 조건 |
|---|---|
| 계획서 + 설계 명세 | 범위가 작을 때. 분량이 적어 나눌 이유가 없다 |
| 설계 명세 + 케이스 명세 | 조건이 10개 안쪽일 때 |
| 케이스 명세 → 도구로 대체 | 테스트 관리 도구를 쓰면 문서 대신 링크 |
| 실행 기록 → 도구로 대체 | 런 기록이 도구에 남는다 |
| 상태 보고 → 대시보드 링크 | 숫자를 손으로 적지 않는다 |
| 완료 보고서는 합치지 않는다 | 유일하게 사람이 읽는 문서다 |
마지막 줄이 원칙이다. 다른 문서는 도구로 대체하거나 합칠 수 있지만, 완료 보고서는 판단과 해석이 담기는 문서라 대체할 수 없다(모듈 6 레슨 5의 "숫자 + 비교 + 해석 + 권고").
다만 감사 대상이면 주의할 것이 하나 있다 — "도구로 대체" 가 심사 시점에 접근 가능한지 확인해야 한다. 외부 심사자가 우리 도구를 못 보면 그 링크는 증거가 아니다. 그 경우 제출 시점에 내보내기(export) 로 뽑는다.
문서 간 불일치가 생기는 지점
감사·검수에서 가장 많이 지적되는 것이 문서끼리 어긋나는 것이다. 어긋나는 곳이 정해져 있으니 제출 전에 그 네 곳만 보면 된다.
| 확인 | 어긋나는 모습 |
|---|---|
| 계획 범위 ↔ 실행 결과 | 계획에 있는데 실행 기록에 없다 |
| 계획 종료 조건 ↔ 완료 보고 | 조건을 못 채웠는데 "완료" 로 적혀 있다 |
| 조건 ↔ 케이스 | 조건에 케이스가 없다(레슨 5) |
| 결함 수 | 완료 보고의 숫자와 도구의 숫자가 다르다 |
두 번째가 가장 치명적이다. "미해결 S1 0건" 이라는 종료 조건을 두고 S1 1건이 남은 채 완료 보고를 쓰면, 그것은 문서가 스스로 모순하는 상태다. 올바른 처리는 예외로 기록하는 것이다(레슨 3) — "종료 조건 미충족, S1 1건 잔존, 책임자 승인 및 해소 기한 10-15".
네 번째는 손으로 적는 숫자에서 거의 항상 발생한다. 도구에서 끌어오면 사라지는 문제다(모듈 7 레슨 7).
사례 — 제출 전 자가 점검으로 반려를 막았다
레슨 1에서 반려를 겪은 팀이 다음 납품에서 제출 전 점검표를 돌렸다. 30분이 걸렸고, 네 가지가 걸렸다.
| 걸린 것 | 수정 |
|---|---|
| 계획서에 중단·재개 기준이 비어 있었다 | 두 줄 추가 |
| 완료 보고의 결함 수가 도구와 2건 차이 | 도구에서 다시 뽑음(중복 종결 2건) |
| 계획에 있던 성능 테스트가 실행 기록에 없음 | 미실시 사유 추가 |
| 추적표에 케이스 없는 요구 1건 | 케이스 2개 추가 작성 후 실행 |
네 번째가 가장 값졌다. 형식 점검을 하다가 실제 검증 공백을 발견한 것이다 — REQ-022에 케이스가 하나도 없었고, 그 요구는 "비밀번호 재설정 링크 유효기간" 이었다. 케이스를 만들어 돌려 보니 결함이 하나 나왔다.
이번 납품은 반려 없이 통과했다. 그런데 팀이 얻은 더 큰 것은 다른 데 있었다 — 점검표가 테스트 품질 점검으로도 작동한다는 발견이다. 문서 간 일관성을 맞추는 작업이 내용의 공백을 드러낸다.
그래서 이 점검표를 표준을 요구하지 않는 프로젝트에도 쓰기로 했다. 제출할 곳이 없어도, 계획과 실행이 어긋난 곳을 찾는 것은 유용하다.
문서들이 어떻게 이어지는가
테스트 계획서 (레슨 4)
→ 테스트 설계 명세 (레슨 5)
→ 테스트 케이스 명세 (모듈 3과 동일한 형식)
→ 실행 → 인시던트 발견 시 결함 리포트 (모듈 6)
→ 테스트 완료 보고서 (레슨 4)
→ 배운 점이 조직 테스트 전략(레슨 3)에 다시 반영됨이 흐름을 보면, 표준의 4개 파트와 3개 프로세스 계층이 별개의 지식이 아니라 하나의 프로젝트를 처음부터 끝까지 관통하는 하나의 이야기임을 알 수 있다. 그리고 이 강의에서 이미 배운 모듈 3(설계), 모듈 4(계획), 모듈 6(결함 리포트)의 내용이, 표준이라는 공식 틀 안에서 그대로 재사용된다는 것도 확인할 수 있다.
실무에서 왜 필요한가
표준을 요구하는 조직(금융, 공공, 의료기기)에 QA로 합류하면, 첫 업무가 "우리 표준 양식에 맞춰 테스트 계획서를 작성해주세요"인 경우가 흔하다. 이 레슨에서 본 것처럼 실제 내용은 이미 배운 것과 크게 다르지 않다 — 다만 정해진 형식과 문서 간 연결 관계를 지켜야 한다는 점이 다르다. 표준 문서 체계를 한 번 끝까지 따라가 본 경험이 있으면, 어떤 조직의 표준 양식을 받아도 "이건 계획서구나, 이건 설계 명세구나"를 빠르게 파악할 수 있다.
양식이 달라도 항목은 같다
조직마다 양식 이름과 순서가 다르다. 그런데 묻는 것은 거의 같다. 이 레슨의 항목 목록을 알고 있으면 처음 보는 양식도 20분이면 채울 수 있다.
| 조직이 뭐라고 부르든 | 실제로 묻는 것 |
|---|---|
| "테스트 계획서", "시험 계획서", "검증 계획" | 범위·리스크·종료 조건 |
| "시험 항목표", "검증 항목서" | 조건과 케이스 |
| "시험 결과서", "검증 결과 보고" | 실행 결과와 못 한 것 |
| "추적 매트릭스", "요구 대조표" | 요구 ↔ 케이스 연결 |
왼쪽 이름에 당황하지 않는 것이 이 레슨의 실용적 성과다. 공공·금융 사업에서는 "시험" 이라는 말을 쓰는 경우가 많은데, 내용은 같다.
점검표가 품질 점검으로도 작동한다
사례에서 본 것이 이 레슨의 숨은 가치다. 문서 간 일관성을 맞추는 작업이 내용의 공백을 드러낸다.
| 문서 점검 | 드러나는 것 |
|---|---|
| 조건에 케이스가 있나 | 경계·예외 미설계(레슨 5) |
| 요구에 케이스가 있나 | 검증되지 않은 요구 |
| 계획 범위가 실행됐나 | 조용히 생략된 영역 |
| 종료 조건이 충족됐나 | 기록되지 않은 예외 |
그래서 표준을 요구하지 않는 프로젝트에도 이 점검을 쓸 가치가 있다. 제출할 곳이 없어도 공백은 찾아야 한다.
형식보다 내용이 먼저다
반대 방향의 주의도 필요하다. 양식을 완벽히 채웠지만 케이스가 경계값을 안 보고 있으면 그 문서는 보기 좋은 껍데기다. 레슨 1에서 본 "표준은 테스트를 더 잘하게 만드는 마법이 아니다" 가 여기서 구체화된다.
판단 기준은 단순하다 — 이 문서를 읽은 사람이 "무엇을 봤고 무엇을 못 봤는지" 알 수 있나. 알 수 있으면 좋은 문서이고, 양식은 그다음이다.
채용시장에서의 위치
이 레슨의 내용은 규제·공공·금융 QA 공고의 실무 요건이다. 그리고 면접에서 문서를 써 본 사람과 양식만 받아 채운 사람이 갈린다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "테스트 계획서를 써 보셨어요?" | "양식에 맞춰 작성했습니다" | "진입·종료 조건과 중단·재개 기준까지 썼습니다. 그 둘이 가장 많이 지적됩니다" |
| "추적표는 어떻게 만드세요?" | "엑셀로 정리합니다" | "도구에서 뽑습니다. 손으로 만들면 어긋나고, 케이스 없는 요구를 찾는 게 목적입니다" |
| "완료 보고서에 꼭 넣는 것은?" | "결과와 결함 현황" | "못 한 것입니다. 계획 범위와 실제가 다르면 그 차이를 설명해야 합니다" |
| "문서가 많으면 부담인데요" | "그래도 해야 합니다" | "합칠 수 있습니다. 다만 완료 보고서는 합치지 않습니다 — 유일하게 사람이 읽는 문서라서요" |
| "제출 전에 뭘 확인하세요?" | "오타와 형식" | "문서 간 불일치 네 곳입니다. 그 점검이 검증 공백도 드러냅니다" |
세 번째와 다섯 번째가 가장 변별력이 크다. 둘 다 제출·심사를 겪어 본 사람의 답이고, 특히 다섯 번째는 형식 점검을 품질 점검으로 쓸 줄 아는 사람의 답이다.
네 번째도 좋다. 문서를 줄일 수 있다는 것과 줄이면 안 되는 하나를 아는 것이 테일러링을 이해한 증거다(레슨 1).
공고 표현으로는 "테스트 산출물 작성", "시험 계획·결과서", "검증 문서 작성", "추적성 관리", "감리 대응" 이 이 레슨에 걸린다.