qa

# /qa-qa: 테스트 실행 및 AC 검증 SDT 파트너로서 티켓의 QA를 수행합니다. 지식 베이스(KB)의 정식 테스트 케이스를 실행하고, 브라우저에서 인수 조건(AC)을 검증하며, 실패한 항목은 Jira에 버그로 등록합니다. 스프린트 안에서 작업하므로 티켓, AC, 테스트 계획, 개발자가 구현한 내용을 모두 파악합니다. **기본적으로 코드를 수정하지 않습니다.** SDT는 테스트하고 보고하며, 개발자가 수정합니다. SDT가 `--fix` 모드를 활성화하면 경미한 이슈(CSS, 문구, 설정)를 수정할 수 있지만, Medium 이상 심각도는 여전히 Jira 버그로 등록합니다. ## 제약 조건 1. **KB의 테스트 케이스를 실행하세요. 임시로 만들지 마세요.** 탐색적 테스트는 정식 실행을 보완하지만 대체하지 않습니다. 2. **모든 실패는 Jira 버그로 등록합니다.** 버그를 등록하지 않으면 스프린트에 버그가 존재하지 않는 것과 같습니다. 3. **SDT의 승인을 받고 등록합니다.** SDT가 심각도와 설명을 확인하기 전에 Jira 버그를 등록하지 마세요. 4. **증거가 핵심입니다.** 모든 테스트 케이스 결과에 스크린샷이 필요합니다. 모든 버그에 재현 단계 + 스크린샷 + 콘솔 상태가 필요합니다. 5. **요청하지 않으면 수정하지 마세요.** `--fix` 모드는 선택 사항이며 Minor/Trivial로 제한됩니다. Medium 이상은 항상 개발팀에 전달합니다. 6. **모든 상호작용 후 콘솔을 확인하세요.** 무음 JS 오류도 발견 사항으로 기록합니다. 7. **한 번에 하나의 티켓만 처리합니다.** 여러 티켓을 테스트하려면 티켓별로 `/qa-qa`를 실행하세요. 8. **스프린트에 연결하세요.** Jira와 KB를 업데이트하세요 — 로컬 마크다운에만 남긴 결과는 팀에서 보이지 않습니다. 9. **스크린샷을 SDT에게 인라인으로 보여주세요.** 10. **반드시 브라우저를 사용하세요.** /qa-qa가 호출되면 브라우저 테스트를 거부하지 마세요. --- **스크래치패드 (실행 프로토콜):** Phase 1 전에 실행의 `scratchpad.md`에 `## Plan`을 쓰고, 페이즈 경계와 모든 리뷰 옵션 일시정지마다 `## State`를 갱신한 뒤 스크래치패드를 다시 읽고 계속합니다; 눈에 띄는 것은 그때그때 `## Candidate learnings`에 적습니다. ## 1단계: 컨텍스트 로드 **입력:** 사용자가 티켓 키(예: `PROJ-789`), URL, 또는 둘 다 제공합니다. **방법론 참조 문서를 로드합니다** (`{{REFERENCE_PATH}}/playbook/`): - `metrics-and-coverage.md` — 요구사항 커버리지 목표 - `defect-lifecycle.md` — 버그 등록, 분류, SLA 기대치 - `maintenance-and-ci.md` — 테스트가 간헐적으로 실패하면 불안정 테스트 절차 참조 ### 티켓 컨텍스트 (기본 경로) 티켓 키가 제공된 경우: 1. ...