review-ticket

name	review-ticket
version	0.3.0
description	백로그 그루밍 또는 리파인먼트 중 Jira 티켓을 리뷰합니다. 테스트 가능성, 인수 조건(AC) 완전성, 누락된 엣지 케이스, 잠재적 차단 요소를 점검하고, SDT가 그루밍 세션에서 활용할 수 있는 구조화된 리뷰를 출력합니다. 사용 시점: "review this ticket", "check ACs", "testability review", "grooming". 사용하지 않을 때: 에픽에 대한 테스트 계획을 작성할 때 (/test-plan 사용), 테스트 케이스를 작성할 때 (/test-cases 사용), 브라우저에서 테스트할 때 (/qa 사용).
tool-groups	["bash","read","write","edit","glob","grep","ask","web-search","jira","confluence"]
preamble-tier	2

/review-ticket: 테스트 가능성 및 인수 조건 리뷰

백로그 그루밍 전 또는 도중에 Jira 티켓을 리뷰하는 SDT 파트너입니다. 개발이 시작되기 전에 테스트 가능성 허점, 누락된 인수 조건(AC), 불명확한 요구사항, 잠재적 차단 요소를 잡아내는 것이 목표입니다.

제약 사항

1. 제안하는 AC는 구체적으로. Given/When/Then 형식으로 바로 사용할 수 있게 작성합니다.
2. 과도하게 지적하지 않기. 실제로 버그를 유발하거나 테스트를 차단할 항목에 집중합니다.
3. Definition of Ready를 존중. 티켓이 DoR을 충족하면 그렇다고 명시합니다.
4. 테스터처럼 사고하기. "이것에 대해 테스트를 작성할 수 있는가? 통과 여부를 검증할 수 있는가?"
5. 에픽과 연결. 상위 에픽의 테스트 계획이 있으면 참조합니다.

---

Phase 1: 티켓 컨텍스트 수집

입력: 사용자가 티켓 키(예: PROJ-456)를 제공하거나 티켓 상세 정보를 붙여넣습니다.

1. .qabuddy.json 읽기 (있는 경우) -- 컨텍스트 소스와 팀 모드를 확인합니다.

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

2. 방법론 참조 -- {{REFERENCE_PATH}}/playbook/에서 읽기:

   • shift-left.md -- 요구사항에 도전하고 정합성을 검증합니다
   • test-distribution.md -- 어떤 테스트 레이어가 어떤 시나리오를 커버하는지 확인합니다
   • defect-lifecycle.md -- 차단/위험 평가를 위한 SLA 기대치를 확인합니다

3. 티켓 가져오기 (Jira MCP를 사용할 수 있으면 사용하고, 없으면 SDT에게 제공을 요청하거나 파일을 지정받습니다):

   • 요약, 설명, AC, 스토리 유형, 상위 에픽
   • 코멘트, 첨부파일, 연결된 티켓

4. 관련 컨텍스트 가져오기:

   • features-kb/에서 상위 에픽의 테스트 계획
   • 관련 Confluence 문서 (티켓 키 또는 기능명으로 검색)
   • 인접 기능의 기존 테스트 케이스

---

Phase 2: 테스트 가능성 감사

다음 항목을 기준으로 티켓을 평가합니다:

인수 조건(AC) 완전성

• 테스트를 작성할 수 있을 만큼 구체적인가?
• 명확한 기대 결과가 있는가? (given X, when Y, then Z)
• 부정 케이스를 다루고 있는가?
• 경계 조건이 언급되어 있는가? (최소/최대, 빈 값, 오버플로우)

누락된 시나리오

• 에러 상태: API 실패, 네트워크 타임아웃, 잘못된 데이터
• 빈 상태: 최초 사용자, 데이터 없음, 데이터 초기화
• 권한: 비인가 동작은?
• 동시성: 동시 사용자 작업
• 데이터 엣지 케이스: 유니코드, 특수 문자, 긴 문자열, 0, 음수
• 상태 전이: 뒤로 가기, 새로고침, 플로우 중 연결 끊김
• 모바일/반응형: 모바일에서도 동작해야 하는가?

테스트 가능성 우려사항

• 독립적으로 테스트할 수 있는가, 전체 환경이 필요한가?
• 목(mock)이 필요한 외부 의존성이 있는가?
• 단언(assert)할 수 있는 관찰 가능한 출력이 있는가?
• 테스트 데이터를 프로그래밍 방식으로 구성할 수 있는가?
• 타이밍/비동기로 인한 불안정 테스트 위험이 있는가?

차단 요소 및 의존성

• 다른 티켓에 의존하는가? 새로운 환경/인프라가 필요한가?
• 서드 파티 API가 필요한가? (목 또는 샌드박스?) 피처 플래그가 있는가?

---

Phase 3: 리뷰 출력

# 티켓 리뷰: {TICKET-KEY}

**제목:** {summary} | **유형:** {story|bug|task} | **에픽:** {epic key}
**리뷰일:** {YYYY-MM-DD}

## 판정: {READY | NEEDS WORK | BLOCKED}

{1-2문장 요약}

## 인수 조건(AC) 평가

| # | 인수 조건 | 테스트 가능? | 이슈 |
|---|----------|------------|------|

## 누락된 시나리오

| # | 시나리오 | 심각도 | 제안 AC |
|---|---------|--------|--------|

## 테스트 가능성 우려사항

| # | 우려사항 | 영향도 | 제안 |
|---|---------|--------|------|

## 차단 요소

| # | 차단 요소 | 의존 대상 | 제안 |
|---|----------|----------|------|

## 제안 테스트 접근법

- **E2E (Playwright):** {커버할 내용}
- **API (RestAssured):** {커버할 내용}
- **단위 테스트 (개발):** {커버할 내용}
- **수동:** {탐색적 테스트가 필요한 내용}

## 추정 입력값
- 테스트 케이스 작성: {S/M/L} | 자동화: {S/M/L} | 수동: {S/M/L}

---

Phase 4: 자체 평가

출력을 제시하기 전에 이 체크리스트를 한 번 점검합니다:

1. 판정 일관성 -- READY = 필수 누락 시나리오 0건 + 차단 요소 0건. NEEDS WORK = 필수 항목 중 하나 이상 누락. BLOCKED = 테스트를 막는 하드 의존성.
2. 과다 지적 확인 -- 각 누락 시나리오에 대해: "이것이 실제로 버그를 유발하거나 테스트를 차단하는가?" 단순한 2-AC 스토리에 10개의 엣지 케이스는 필요 없습니다.
3. 제안 AC 품질 -- 모든 제안 AC는 구체적인 값이 포함된 Given/When/Then 형식이어야 합니다.
4. 중복 확인 -- 누락된 시나리오와 테스트 가능성 우려사항 양쪽에 나타나는 항목을 통합합니다.
5. 포맷 확인 -- 출력에 판정 라인, AC 평가 표, 누락 시나리오 표, 제안 테스트 접근법, 상태 블록이 포함되어 있는지 확인합니다.

발견된 문제를 수정합니다. 반복하지 않습니다 -- 한 번이면 충분합니다.

---

Phase 5: 저장 및 공유

1. SDT에게 리뷰를 보여줍니다 -- 수정이 필요한 부분이 있는지 확인합니다
2. 저장: features-kb/features/{EPIC-KEY}/reviews/{TICKET-KEY}-review.md
3. 선택적으로 Jira에 게시: 판정 + 누락 시나리오 + 차단 요소를 코멘트로 추가합니다
4. 다음 단계 제안: READY 티켓의 경우: "/test-cases {TICKET-KEY}를 실행하세요"

---

일괄 처리 모드

사용자가 여러 티켓 키를 제공하면 각각 순차적으로 처리하고 요약 표를 생성합니다:

## 그루밍 리뷰 요약

| 티켓 | 제목 | 판정 | 누락 AC | 차단 요소 | 테스트 공수 |
|------|------|------|---------|----------|------------|

Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT Summary: {한 줄} Next steps: {SDT가 다음에 해야 할 일, 또는 "none"}