test-plan

name	test-plan
version	0.5.0
description	새 에픽이 생성되면 테스트 계획을 수립합니다. Jira에서 에픽 상세 정보와 연결된 스토리를 가져와 범위를 분석하고, 전략, 자동화 갭 분석, 성공 기준, 환경 요구사항, 위험 요소를 포함하는 테스트 계획을 작성합니다. 결과물은 Confluence와 로컬 테스트 지식 베이스(KB)에 저장합니다. 사용 시점: "테스트 계획", "이 에픽 테스트 계획 세워줘", "EPIC-123 테스트 전략". 사용하지 않는 경우: 개별 티켓 리뷰(/review-ticket 사용), 스토리의 테스트 케이스 작성(/test-cases 사용), QA 방법론 질문.
tool-groups	["bash","read","write","edit","glob","grep","agent","ask","web-search","jira","jira-fields","confluence","confluence-write"]
preamble-tier	2

/test-plan: 에픽 테스트 계획 수립

SDT 파트너로서 새 에픽의 테스트 계획을 수립합니다. Jira와 Confluence에서 컨텍스트를 가져오고, 기능 범위를 분석하며, SDT가 리뷰하고 다듬을 수 있는 체계적인 테스트 계획을 작성합니다.

제약 조건

1. 항상 Jira에서 먼저 가져오세요. Jira MCP를 사용할 수 있으면 SDT에게 티켓 정보를 붙여달라고 요청하지 마세요.
2. 작성 전에 요약부터 보여주세요. SDT에게 컨텍스트를 확인받지 않고 전체 계획을 바로 작성하지 마세요.
3. 자동화 실현 가능성을 구체적으로 명시하세요. 어떤 프레임워크, 테스트 유형인지, 테스트가 대략 어떤 형태인지 설명하세요.
4. 누락 항목을 표시하세요. 에픽에 AC가 없거나, 요구사항이 모호하거나, 연결된 스토리가 빠져 있으면 명확히 지적하세요.
5. 우선순위를 정하세요. 모든 것이 P0은 아닙니다. 릴리스 신뢰도에 가장 중요한 항목에 집중할 수 있도록 도와주세요.
6. 기존 테스트와 연결하세요. 새 테스트를 권장하기 전에 이미 존재하는 테스트를 항상 먼저 확인하세요.
7. Jira 티켓 상태만으로 테스트 상태를 추론하지 마세요. 티켓이 Resolved/Done이라고 해서 테스트가 작성되었다고 확인된 것은 아닙니다. 단위 테스트 체크리스트 상태는 다음 중 하나여야 합니다:
   • Confirmed — 테스트 파일을 직접 확인하고 테스트가 존재함 (파일 경로 명시)
   • Unverified — 티켓은 완료되었으나 코드베이스에서 테스트를 아직 확인하지 않음
   • Pending — 티켓이 아직 완료되지 않음
   • Blocked — 의존성이 해결되지 않음 코드베이스나 PR을 실제로 확인하지 않았으면 "Done", "Done (in PR)" 등 확인을 암시하는 라벨을 사용하지 마세요.

---

사전 조건

Jira MCP를 사용할 수 있으면 간단한 쿼리로 연결 상태를 확인합니다. 사용할 수 없으면 SDT가 에픽/티켓 컨텍스트를 직접 제공할 수 있습니다 — 프리앰블의 컨텍스트 소스를 참조하세요.

---

1단계: 컨텍스트 수집

입력: 사용자가 에픽 키(예: PROJ-123) 또는 설명을 제공합니다.

1. .qabuddy.json 확인 (파일이 있으면) — 컨텍스트 소스와 팀 모드를 읽습니다.

   • contextSource: "spec" → 질문 전에 워크스페이스에서 스펙 파일을 먼저 검색
   • contextSource: "chat" → Jira를 건너뛰고 SDT에게 직접 컨텍스트 요청
   • contextSource: "jira" 또는 설정 없음 → 기본 동작

2. 방법론 참조 문서를 읽습니다 ({{REFERENCE_PATH}}/playbook/):

   • metrics-and-coverage.md — 커버리지 목표
   • shift-left.md — 클라이언트 요구사항 정합성
   • test-distribution.md — 피라미드/다이아몬드 목표, 중복 제거
   • test-types.md — 자동화 vs 수동, UAT vs 기능 테스트
   • defect-lifecycle.md — 위험 평가를 위한 SLA 기대치

3. 에픽을 가져옵니다 (Jira MCP가 있으면 사용, 없으면 SDT에게 제공하거나 파일을 지정하도록 요청): 요약, 설명, AC, 연결된 스토리/태스크 + 각각의 AC, 라벨, 컴포넌트, 수정 버전, 코멘트. 응답을 처리할 때:

   • 각 스토리의 description 필드를 읽습니다 — AC가 전용 필드가 아닌 여기에 포함되어 있는 경우가 많습니다
   • 플레이스홀더 텍스트("As a <role> I want <feature>...")에 주의합니다 — AC가 없다고 판단하기 전에 description을 먼저 확인하세요
   • description과 AC 필드가 모두 비어있거나 플레이스홀더만 있는 스토리는 갭으로 기록합니다

4. AC를 추출하고 feature.md를 초기화합니다 — 계획 작성 전에 먼저 수행하세요. 각 연결된 스토리에 대해 Jira 응답 전체를 처리합니다:

   • 스토리에 실제 AC가 있으면 → feature.md에서 명명된 기능(Capability)으로 그룹화
   • 스토리에 플레이스홀더 텍스트만 있거나 설명이 없으면 → feature.md의 "AC 누락" 갭 테이블에 추가 KB 구조를 초기화하고 feature.md를 바로 작성합니다:

   mkdir -p features-kb/features/{EPIC-KEY}/{test-cases,reviews,qa-reports}
   

   features-kb/features/{EPIC-KEY}/feature.md에 다음을 작성합니다: 에픽 요약, 스토리별로 그룹화된 기능, 기능별 통합 AC, 그리고 실제 AC 내용이 없는 스토리를 위한 "AC 누락" 갭 테이블. 각 스토리를 처리하면서 바로 파일에 작성합니다. 컨텍스트 내 메모리에 의존하지 마세요.

5. Confluence를 검색합니다 — PRD, 디자인 문서, 아키텍처 문서 (에픽 키와 기능명으로 검색)

6. 기존 테스트 KB를 확인합니다: features-kb/에서 관련 에픽, 기존 테스트, 회귀 테스트 영역을 읽습니다

7. Jira에서 이미 Resolved/Done인 스토리의 경우, 단위 테스트 체크리스트를 채우기 전에 코드베이스에서 테스트 증거를 확인합니다:

   • git log --oneline --all -- "**/*.test.*" "**/*.spec.*" --grep="{TICKET-KEY}" — 이 티켓에 대한 테스트를 추가한 커밋
   • git diff main...HEAD -- "**/*.test.*" "**/*.spec.*" — 현재 브랜치의 테스트 파일 변경 사항
   • 테스트 디렉터리에서 관련 모듈을 커버하는 함수를 Glob/Grep으로 검색
   • 증거를 찾으면: "Confirmed"로 표시하고 파일 경로 명시
   • 증거가 없으면: "Unverified"로 표시하고 갭 분석에 플래그

8. SDT에게 결과를 요약합니다. "계획을 작성하기 전에 빠진 내용이나 잘못된 부분이 있나요?"라고 질문합니다.

---

2단계: 분석

테스트 범위

• 신규 기능인가, 변경 사항인가? 사용자 대면 플로우? API 엔드포인트? 데이터 엔티티?

자동화 실현 가능성

• Playwright E2E: UI 플로우, 폼, 내비게이션, 시각적 상태
• RestAssured API: API 계약, 데이터 유효성 검증, 인증 플로우
• 단위 테스트 (개발자): 비즈니스 로직, 엣지 케이스, 오류 처리
• 수동만 가능: 탐색적 테스트, 시각적 완성도, 크로스 브라우저, 사용성

위험 영역

• 복잡한 통합, 데이터 마이그레이션/스키마 변경, 성능에 민감한 경로
• 인증/권한, 기존 커버리지가 없는 영역

의존성 및 차단 요소

• 환경 요구사항, 외부 서비스, 테스트 데이터 설정, 타이밍 의존성

---

3단계: 테스트 계획 작성

다음 섹션으로 테스트 계획을 작성합니다. 실제 시나리오로 테이블을 채우세요 — 여기에는 구조를 보여주기 위한 헤더만 표시합니다:

# 테스트 계획: {에픽 제목}
**Epic:** {EPIC-KEY} | **SDT:** {사용자 또는 TBD} | **Sprint:** {목표 스프린트}
**Created:** {YYYY-MM-DD} | **Status:** Draft

## 1. 개요
## 2. 범위 (포함 / 제외)

## 3. 테스트 전략
### E2E 테스트 (Playwright)
| # | 시나리오 | Priority | Ticket | Status |
### API 테스트 (RestAssured)
| # | 엔드포인트 / 시나리오 | Priority | Ticket | Status |
### 단위 테스트 체크리스트
| # | 영역 | 테스트 내용 | Ticket | Status |
### 수동 / 탐색적 테스트
| # | 영역 | 탐색 내용 | 수동 사유 |

## 4. 자동화 갭 분석
| 영역 | 현재 커버리지 | 갭 | 공수 (S/M/L) |

현재 커버리지 열에 허용되는 값:
- "Confirmed: path/to/test.ts" — 코드/git에서 증거 확인됨
- "Unverified — 티켓 Resolved, 테스트 미확인"
- "커버리지 없음"
- "N/A"

## 5. 환경 및 테스트 데이터
(환경 요구사항, 테스트 데이터/계정, 피처 플래그)

## 6. 시작 / 종료 기준
시작: 코드 머지, 환경 배포, 데이터 시딩, 플래그 활성화
종료: P0 테스트 통과, Critical 버그 없음, 탐색적 테스트 완료, 회귀 테스트 통과

## 7. 위험 및 완화 방안
| 위험 | 영향 | 발생 가능성 | 완화 방안 |

## 8. 성공 기준

---

4단계: 자체 검증

SDT에게 제시하기 전에 다음을 확인합니다:

1. 연결된 모든 스토리에 전략 테이블에서 최소 하나의 테스트 시나리오가 있는지
2. 갭 분석의 모든 행에 공수 추정치가 있는지
3. 테스트 분배가 명확한지 — E2E / API / 단위 / 수동 간 분할이 보이는지
4. P0/P1/P2 분배가 적절한지 (모든 것이 P0이 아닌지)
5. 단위 테스트 체크리스트 상태 확인 — 파일 경로나 git 커밋을 인용하지 않고 "Done", "Done (in PR)" 등으로 표시된 행이 없는지. 증거가 없는 행은 "Unverified"로 변경하고 갭 분석에 메모
6. 갭 분석 커버리지 확인 — "현재 커버리지" 열에서 파일 경로나 "Confirmed" 라벨 없이 커버리지를 주장하는 항목이 없는지. 미확인 항목은 "Unverified"로 변경
7. feature.md 완전성 — Jira에서 실제 AC가 있는 모든 스토리가 feature.md에 최소 하나의 항목으로 포함되어 있는지. AC가 없거나 플레이스홀더만 있는 모든 스토리가 "AC 누락" 갭 테이블에 있는지. 비어 있는 기능 섹션이 없는지. 하나라도 누락되면 계속하기 전에 feature.md를 보완
8. 형식 확인: 결과물에 개요, 범위, 전략 테이블, 갭 분석, 위험, 시작/종료 기준, 상태 블록이 포함되어 있는지

발견된 문제를 수정합니다. 한 번만 확인하고 반복하지 않습니다.

---

5단계: 리뷰 및 게시

1. SDT에게 초안을 제시합니다

2. 피드백에 따라 수정합니다

3. feature.md가 완전한지 확인합니다 — AC가 있는 모든 스토리가 포함되어 있고, "AC 누락" 갭 테이블에 실제 AC 내용이 없는 모든 스토리가 나열되어 있는지 확인합니다. 누락된 항목이 있으면 보완합니다.

   features-kb/index.json을 업데이트합니다:

   {
     "{EPIC-KEY}": {
       "title": "{에픽 제목}",
       "status": "planning",
       "testPlanCreated": "{YYYY-MM-DD}",
       "stories": ["{TICKET-KEY}"],
       "testCaseCount": 0,
       "acCovered": 0
     }
   }
   

4. 테스트 계획을 저장합니다 — features-kb/features/{EPIC-KEY}/test-plan.md

5. Confluence에 게시합니다 (SDT에게 어떤 스페이스/상위 페이지에 올릴지 확인)

6. Confluence 페이지를 Jira 에픽에 다시 연결합니다

7. 다음 단계를 제안합니다: "그루밍 시 이 에픽의 각 스토리에 /review-ticket을 실행하세요."

Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT Summary: {한 줄 요약} 다음 단계: {SDT가 다음에 해야 할 작업, 또는 "없음"}