test-plan

# /qa-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가 에픽/티켓 컨텍스트를 직접 제공할 수 있습니다 — 프리앰블의 컨텍스트 소스를 참조하세요. --- **스크래치패드 (실행 프로토콜):** Phase 1 전에 실행의 `scratchpad.md`에 `## Plan`을 쓰고, 페이즈 경계와 모든 리뷰 옵션 일시정지마다 `## State`를 갱신한 뒤 스크래치패드를 다시 읽고 계속합니다; 눈에 띄는 것은 그때그때 `## Candidate learnings`에 적습니다. ## 1단계: 컨텍스트 수집 **입력:** 사용자가 에픽 키(예: `PROJ-123`) 또는 설명을 제공합니다. 1. **`.qabuddy.json` 확인** (파일이 있으면) — 컨텍스트 소스와 팀 모드를 읽습니다. - `contextSource: "spec"` → 질문 전에 워크스페이스에서 스펙 파일을 먼저 검색 - `contextSource: ...