---
type: knowledge
domain: product
role: QA·Judge
status: active
last-reviewed: 2026-07-27
---

# QA·Judge 기획 가이드

> QA·Judge의 임무는 원본 요구사항·실제 산출물·직접 실행한 결과를 독립적으로 대조해, 발주사 검수(UAT)에 내놓을 수 있는 PASS/FAIL 증거를 만드는 것이다. **내부 테스트는 발주사 검수의 전 단계다** — 검수장에서 처음 발견되는 실패는 내부 테스트의 실패다.

## 검수·계약과의 연결

- **테스트계획서·테스트케이스·테스트결과서는 납품 산출물이다.** 내부 품질 활동의 부산물이 아니라 검수 서명과 잔금 지급의 근거다 ([[외주 개발 산출물]] §테스트·검수).
- 검수 기준·기대값은 **착수 전 발주사와 합의된 것만 유효**하다. QA가 임의로 만든 기준, 검수 직전에 사후 합의한 기준은 분쟁의 원인이다.
- 현업(발주사)이 수행할 테스트 시나리오 작성법의 정본은 [[시나리오·예외사항 문서 작성법]]이다. 내부 테스트케이스(TC-\*)와 현업 시나리오(US-\*/EX-\*)를 ID로 1:1 추적시켜 검수·회귀·RTM이 한 선으로 이어지게 한다.

## 활성화 조건

- 구현 완료 주장을 독립적으로 검증해야 한다.
- 사용자 경로, API, 데이터, 보안, 성능 또는 회귀 위험이 있다.
- 발주사 검수·마일스톤·계약 게이트에 PASS/FAIL 증거가 필요하다.
- 여러 구현 역할의 통합 결과를 하나의 기준으로 판정해야 한다.

## 독립성 계약

- 구현자의 요약은 탐색 입력일 뿐 합격 근거가 아니다.
- QA는 원본 요구사항과 실제 변경물을 직접 읽고 테스트를 직접 실행한다.
- 같은 사람이 구현과 QA를 맡아도 세션·체크리스트·판정 기록을 분리한다.
- 완료 조건이 없거나 관찰 불가능하면 요구사항 Owner에게 되돌린다. **완료 조건 없이 PASS를 주지 않는다.**

## 필수 입력

| 입력 | 최소 조건 | 없을 때 |
|---|---|---|
| 요구사항·완료 조건 | ID, 우선순위, 발주사와 합의된 PASS/FAIL 기준 | 판정 BLOCKED |
| 테스트 대상 | 버전·commit·환경이 고정됨 | 진입 차단 |
| 설계·계약 | 화면 상태, API, 데이터, NFR | 영향 영역 미검토 표시 |
| 구현·리뷰 결과 | 실제 변경물, 리뷰 발견과 처분 | 잔여 위험 확인 |
| 환경·데이터 | 재현 가능한 환경과 허용된 데이터 | 실행 차단 또는 제한 판정 |

## 결정 순서

1. [[01_테스트 전략·범위]]에서 위험, 테스트 층, 포함·제외 범위를 정한다.
2. [[02_요구사항·테스트 추적표]]에서 모든 완료 조건을 테스트와 1:1로 연결한다.
3. [[03_환경·데이터 계획]]에서 버전, 의존성, 권한, 데이터 초기화를 고정한다.
4. [[04_테스트 케이스·결함 관리]]에 실행 가능한 케이스와 결함 재현법을 작성한다.
5. [[05_진입·종료·판정 기준]]으로 PASS·FAIL·CONDITIONAL·BLOCKED 규칙을 확정한다.
6. 직접 실행 결과를 기록하고 [[90_QA·Judge 완료 체크리스트]]를 통과한다.
7. [[99_QA 판정 템플릿]]으로 Release·운영과 PM·고객·업무책임(검수 회부)에 판정과 잔여 위험을 넘긴다.

## 파일 지도

| 파일 | 질문 | 결과 |
|---|---|---|
| [[01_테스트 전략·범위]] | 어디에 검증 자원을 집중할까? | 테스트계획서의 뼈대 |
| [[02_요구사항·테스트 추적표]] | 모든 완료 조건이 검증되는가? | 추적선(RTM 테스트 구간) |
| [[03_환경·데이터 계획]] | 결과를 재현할 수 있는가? | 실행 기반 |
| [[04_테스트 케이스·결함 관리]] | 무엇을 어떻게 실행하고 실패를 남길까? | 케이스·결함 원장 |
| [[05_진입·종료·판정 기준]] | 언제 시작·종료하고 어떤 판정을 내릴까? | 판정 계약 |
| [[90_QA·Judge 완료 체크리스트]] | 독립 판정 준비가 끝났는가? | 자체 게이트 |
| [[99_QA 판정 템플릿]] | 승인자가 무엇을 근거로 결정할까? | 최종 판정(테스트결과서 원천) |

## 산출물과 소비자

| 산출물 | 소비자 | 요청 행동 |
|---|---|---|
| 요구↔테스트 추적표 | PM·Tech Lead | 누락된 기준 보완, RTM 갱신 |
| 실행 결과·결함 | 구현자·리뷰어 | 수정·재현 |
| 회귀·NFR 결과 | Release·운영 | 이관·오픈 위험 평가 |
| QA 판정·테스트결과서 | PM·고객·업무책임 | 발주사 검수(UAT) 회부, 조건부 승인·반려 결정 |

## 역할 경계

- QA는 요구사항을 사후 완화하거나 범위·우선순위를 바꾸지 않는다. 테스트 중 발견한 범위 밖 요구는 결함이 아니라 **CR 후보로 분리해 PM에 회부**한다.
- QA는 구현자의 자기 검증과 리뷰어의 코드·문서 의견을 대체하지 않으며, **발주사 검수(UAT)를 대신하지 않는다** — 내부 PASS는 검수 회부 조건이지 검수 통과가 아니다.
- **QA는 실행해서 판정한다** (동적: 요구 ↔ 실행 결과). 실행 없이 코드·문서를 계약과 대조하는 것은 리뷰어의 몫이다 — 같은 결함을 두 대장에 이중 기록하지 않고, 리뷰어 발견은 리뷰 기록으로, 실행 결함은 결함 원장(BUG-\*)으로 남긴다.
- 미수행은 PASS가 아니다. 범위 밖, 환경 차단, 판정 불가는 각각 드러낸다.
- QA 판정은 병합·운영 배포에 필요한 사람 승인을 대신하지 않는다.

## 진입·종료 게이트

**진입:** 발주사와 합의된 완료 조건, 테스트 대상 버전, 환경·데이터, 알려진 위험과 리뷰 결과가 준비됐다.

**종료:** 모든 완료 조건에 결과·증거가 있고, 미수행이 통과로 계산되지 않았으며, 차단 결함과 예외 승인 상태가 명확하다. 테스트계획서·테스트케이스·테스트결과서가 **검수·계약 근거로 제출 가능한 상태**다. 완료 조건 누락 상태에서는 어떤 경우에도 PASS가 아니다.

## 관련 문서

- [[00_역할별 기획 허브]]
- [[00_역할별 기획 운영 가이드]]
- [[역할별 개발 산출물]]
- [[외주 개발 산출물]]
- [[SI 수주와 범위 관리]]
- [[시나리오·예외사항 문서 작성법]]
- [[QA 원리]]
- [[테스트 전략 실전]]
- [[요구사항과 완료 조건]]