test-cases

# /qa-test-cases: AC에서 테스트 케이스 생성 SDT 파트너로서 티켓의 테스트 케이스를 생성합니다. Jira에서 티켓의 AC를 가져오고, 에픽 테스트 계획과 대조하여 다음을 작성합니다: 1. E2E 테스트 시나리오 (단계와 기대 결과 — 구현은 `/qa-e2e-write`가 담당) 2. 단위 테스트 체크리스트 (개발자용) 3. 요구사항-테스트 매핑 (추적성 확보) ## 제약 조건 1. **프로젝트의 테스트 스타일에 맞추세요.** 기존 Playwright 테스트를 먼저 읽으세요. 동일한 패턴, import, 헬퍼, 페이지 오브젝트를 사용하세요. 2. **테스트 케이스에 구현 코드를 넣지 않습니다.** 단계와 기대 결과가 계약입니다; 셀렉터·대기·fixture는 `/qa-e2e-write`의 소유입니다. 작성자가 알아야 할 자동화 제약(격리, 1회 실행, 데이터 위생)은 사전 조건에 적습니다. 3. **모든 테스트 케이스는 요구사항에 매핑됩니다.** 고아 테스트도 없고, 테스트되지 않은 AC도 없어야 합니다. 4. **단위 테스트 체크리스트는 개발자용입니다.** 간결하고 실행 가능하게 작성하세요 — 무엇을 테스트할지 설명하고, 방법은 적지 마세요. 5. **기존 테스트와 중복하지 마세요.** 이미 커버되는 시나리오가 있으면 새로 만들지 말고 참조하세요. 6. **우선순위를 과감하게 정하세요.** AC가 3개인 티켓에 테스트 케이스 30개가 필요하지 않습니다. 실제 버그를 잡아내는 데 집중하세요. 7. **관찰이 추정을 이깁니다.** 컨트롤 라벨, 시드 데이터, 화면에 표시되는 값, 브라우저가 보내는 요청을 지명하는 사전 조건이나 단계는 실행 중인 앱에서 확인한 것(1단계 8번)이거나, `/qa-e2e-pom`이 확정하도록 `(unverified)` 표시를 달아야 합니다. 직접 지켜보지 않은 페이지의 네트워크 동작을 단언하지 마세요. --- **스크래치패드 (실행 프로토콜):** Phase 1 전에 실행의 `scratchpad.md`에 `## Plan`을 쓰고, 페이즈 경계와 모든 리뷰 옵션 일시정지마다 `## State`를 갱신한 뒤 스크래치패드를 다시 읽고 계속합니다; 눈에 띄는 것은 그때그때 `## Candidate learnings`에 적습니다. ## 1단계: 컨텍스트 수집 **입력:** 사용자가 티켓 키(예: `PROJ-789`)를 제공하거나 티켓 상세 정보를 붙여넣습니다. 1. **`.qabuddy.json` 확인** (파일이 있으면) — 컨텍스트 소스와 팀 모드를 읽습니다. - `contextSource: "spec"` → 질문 전에 워크스페이스에서 스펙 파일을 먼저 검색 - `contextSource: "chat"` → Jira를 건너뛰고 SDT에게 직접 컨텍스트 요청 - `contextSource: "jira"` 또는 설정 없음 → 기본 동작 2. **방법론 참조 문서를 읽습니다** (`{{REFERENCE_PATH}}/playbook/`): - `test-distributi...