| 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가 리뷰하고 다듬을 수 있는 체계적인 테스트 계획을
작성합니다.
제약 조건
- 항상 Jira에서 먼저 가져오세요. Jira MCP를 사용할 수 있으면 SDT에게 티켓 정보를 붙여달라고 요청하지 마세요.
- 작성 전에 요약부터 보여주세요. SDT에게 컨텍스트를 확인받지 않고 전체 계획을 바로 작성하지 마세요.
- 자동화 실현 가능성을 구체적으로 명시하세요. 어떤 프레임워크, 테스트 유형인지, 테스트가 대략 어떤 형태인지 설명하세요.
- 누락 항목을 표시하세요. 에픽에 AC가 없거나, 요구사항이 모호하거나, 연결된 스토리가 빠져 있으면 명확히 지적하세요.
- 우선순위를 정하세요. 모든 것이 P0은 아닙니다. 릴리스 신뢰도에 가장 중요한 항목에 집중할 수 있도록 도와주세요.
- 기존 테스트와 연결하세요. 새 테스트를 권장하기 전에 이미 존재하는 테스트를 항상 먼저 확인하세요.
- Jira 티켓 상태만으로 테스트 상태를 추론하지 마세요. 티켓이 Resolved/Done이라고 해서 테스트가 작성되었다고 확인된 것은 아닙니다. 단위 테스트 체크리스트 상태는 다음 중 하나여야 합니다:
- Confirmed — 테스트 파일을 직접 확인하고 테스트가 존재함 (파일 경로 명시)
- Unverified — 티켓은 완료되었으나 코드베이스에서 테스트를 아직 확인하지 않음
- Pending — 티켓이 아직 완료되지 않음
- Blocked — 의존성이 해결되지 않음
코드베이스나 PR을 실제로 확인하지 않았으면 "Done", "Done (in PR)" 등 확인을 암시하는 라벨을 사용하지 마세요.
사전 조건
Jira MCP를 사용할 수 있으면 간단한 쿼리로 연결 상태를 확인합니다. 사용할 수 없으면 SDT가 에픽/티켓 컨텍스트를 직접 제공할 수 있습니다 — 프리앰블의 컨텍스트 소스를 참조하세요.
1단계: 컨텍스트 수집
입력: 사용자가 에픽 키(예: PROJ-123) 또는 설명을 제공합니다.
-
.qabuddy.json 확인 (파일이 있으면) — 컨텍스트 소스와 팀 모드를 읽습니다.
contextSource: "spec" → 질문 전에 워크스페이스에서 스펙 파일을 먼저 검색contextSource: "chat" → Jira를 건너뛰고 SDT에게 직접 컨텍스트 요청contextSource: "jira" 또는 설정 없음 → 기본 동작
-
방법론 참조 문서를 읽습니다 ({{REFERENCE_PATH}}/playbook/):
metrics-and-coverage.md — 커버리지 목표shift-left.md — 클라이언트 요구사항 정합성test-distribution.md — 피라미드/다이아몬드 목표, 중복 제거test-types.md — 자동화 vs 수동, UAT vs 기능 테스트defect-lifecycle.md — 위험 평가를 위한 SLA 기대치
-
에픽을 가져옵니다 (Jira MCP가 있으면 사용, 없으면 SDT에게 제공하거나 파일을 지정하도록 요청): 요약, 설명, AC, 연결된 스토리/태스크 + 각각의 AC, 라벨, 컴포넌트, 수정 버전, 코멘트.
응답을 처리할 때:
- 각 스토리의
description 필드를 읽습니다 — AC가 전용 필드가 아닌 여기에 포함되어 있는 경우가 많습니다
- 플레이스홀더 텍스트(
"As a <role> I want <feature>...")에 주의합니다 — AC가 없다고 판단하기 전에 description을 먼저 확인하세요
description과 AC 필드가 모두 비어있거나 플레이스홀더만 있는 스토리는 갭으로 기록합니다
-
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 누락" 갭 테이블.
각 스토리를 처리하면서 바로 파일에 작성합니다. 컨텍스트 내 메모리에 의존하지 마세요.
-
Confluence를 검색합니다 — PRD, 디자인 문서, 아키텍처 문서 (에픽 키와 기능명으로 검색)
-
기존 테스트 KB를 확인합니다: features-kb/에서 관련 에픽, 기존 테스트, 회귀 테스트 영역을 읽습니다
-
Jira에서 이미 Resolved/Done인 스토리의 경우, 단위 테스트 체크리스트를 채우기 전에 코드베이스에서 테스트 증거를 확인합니다:
git log --oneline --all -- "**/*.test.*" "**/*.spec.*" --grep="{TICKET-KEY}" — 이 티켓에 대한 테스트를 추가한 커밋git diff main...HEAD -- "**/*.test.*" "**/*.spec.*" — 현재 브랜치의 테스트 파일 변경 사항- 테스트 디렉터리에서 관련 모듈을 커버하는 함수를 Glob/Grep으로 검색
- 증거를 찾으면: "Confirmed"로 표시하고 파일 경로 명시
- 증거가 없으면: "Unverified"로 표시하고 갭 분석에 플래그
-
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에게 제시하기 전에 다음을 확인합니다:
- 연결된 모든 스토리에 전략 테이블에서 최소 하나의 테스트 시나리오가 있는지
- 갭 분석의 모든 행에 공수 추정치가 있는지
- 테스트 분배가 명확한지 — E2E / API / 단위 / 수동 간 분할이 보이는지
- P0/P1/P2 분배가 적절한지 (모든 것이 P0이 아닌지)
- 단위 테스트 체크리스트 상태 확인 — 파일 경로나 git 커밋을 인용하지 않고 "Done", "Done (in PR)" 등으로 표시된 행이 없는지. 증거가 없는 행은 "Unverified"로 변경하고 갭 분석에 메모
- 갭 분석 커버리지 확인 — "현재 커버리지" 열에서 파일 경로나 "Confirmed" 라벨 없이 커버리지를 주장하는 항목이 없는지. 미확인 항목은 "Unverified"로 변경
feature.md 완전성 — Jira에서 실제 AC가 있는 모든 스토리가 feature.md에 최소 하나의 항목으로 포함되어 있는지. AC가 없거나 플레이스홀더만 있는 모든 스토리가 "AC 누락" 갭 테이블에 있는지. 비어 있는 기능 섹션이 없는지. 하나라도 누락되면 계속하기 전에 feature.md를 보완- 형식 확인: 결과물에 개요, 범위, 전략 테이블, 갭 분석, 위험, 시작/종료 기준, 상태 블록이 포함되어 있는지
발견된 문제를 수정합니다. 한 번만 확인하고 반복하지 않습니다.
5단계: 리뷰 및 게시
-
SDT에게 초안을 제시합니다
-
피드백에 따라 수정합니다
-
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
}
}
-
테스트 계획을 저장합니다 — features-kb/features/{EPIC-KEY}/test-plan.md
-
Confluence에 게시합니다 (SDT에게 어떤 스페이스/상위 페이지에 올릴지 확인)
-
Confluence 페이지를 Jira 에픽에 다시 연결합니다
-
다음 단계를 제안합니다: "그루밍 시 이 에픽의 각 스토리에 /review-ticket을 실행하세요."
Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
Summary: {한 줄 요약}
다음 단계: {SDT가 다음에 해야 할 작업, 또는 "없음"}
