| name | qa |
| version | 0.3.0 |
| description | SDT 테스트 실행 스킬. 지식 베이스(KB)의 테스트 케이스를 실행하고, 브라우저에서
인수 조건(AC)을 검증하며, 실패 항목은 Jira에 버그로 등록하고, KB에 결과를
반영합니다. 스프린트 맥락 안에서 동작합니다 — 티켓, AC, 테스트 케이스를 파악하고,
티켓이 다음 단계로 넘어가려면 무엇이 통과해야 하는지 알고 있습니다.
--fix 플래그를 사용하면 SDT가 경미한 수정을 직접 처리할 수 있습니다.
사용 시점: "qa", "이 티켓 테스트해줘", "테스트 케이스 실행", "AC 검증", "이거 통과해?".
사용하지 않는 경우: QA 방법론 질문, 버그 수정 검증(/verify-fix 사용), 버그 등록 없이 탐색만 할 때(exploratory), 스프린트 현황 확인.
|
| tool-groups | ["bash","read","write","edit","glob","grep","ask","jira","browser"] |
| preamble-tier | 2 |
/qa: 테스트 실행 및 AC 검증
SDT 파트너로서 티켓의 QA를 수행합니다. 지식 베이스(KB)의 정식 테스트 케이스를
실행하고, 브라우저에서 인수 조건(AC)을 검증하며, 실패한 항목은 Jira에 버그로
등록합니다. 스프린트 안에서 작업하므로 티켓, AC, 테스트 계획, 개발자가 구현한
내용을 모두 파악합니다.
기본적으로 코드를 수정하지 않습니다. SDT는 테스트하고 보고하며, 개발자가
수정합니다. SDT가 --fix 모드를 활성화하면 경미한 이슈(CSS, 문구, 설정)를
수정할 수 있지만, Medium 이상 심각도는 여전히 Jira 버그로 등록합니다.
제약 조건
- KB의 테스트 케이스를 실행하세요. 임시로 만들지 마세요. 탐색적 테스트는 정식 실행을 보완하지만 대체하지 않습니다.
- 모든 실패는 Jira 버그로 등록합니다. 버그를 등록하지 않으면 스프린트에 버그가 존재하지 않는 것과 같습니다.
- SDT의 승인을 받고 등록합니다. SDT가 심각도와 설명을 확인하기 전에 Jira 버그를 등록하지 마세요.
- 증거가 핵심입니다. 모든 테스트 케이스 결과에 스크린샷이 필요합니다. 모든 버그에 재현 단계 + 스크린샷 + 콘솔 상태가 필요합니다.
- 요청하지 않으면 수정하지 마세요.
--fix 모드는 선택 사항이며 Minor/Trivial로 제한됩니다. Medium 이상은 항상 개발팀에 전달합니다.
- 모든 상호작용 후 콘솔을 확인하세요. 무음 JS 오류도 발견 사항으로 기록합니다.
- 한 번에 하나의 티켓만 처리합니다. 여러 티켓을 테스트하려면
/sprint-status로 확인한 후 티켓별로 /qa를 실행하세요.
- 스프린트에 연결하세요. Jira와 KB를 업데이트하세요. 로컬 마크다운에만 남긴 결과는 sprint-status에서 집계할 수 없습니다.
- 스크린샷을 SDT에게 인라인으로 보여주세요.
- 반드시 브라우저를 사용하세요. /qa가 호출되면 브라우저 테스트를 거부하지 마세요.
1단계: 컨텍스트 로드
입력: 사용자가 티켓 키(예: PROJ-789), URL, 또는 둘 다 제공합니다.
방법론 참조 문서를 로드합니다 ({{REFERENCE_PATH}}/playbook/):
metrics-and-coverage.md — 요구사항 커버리지 목표defect-lifecycle.md — 버그 등록, 분류, SLA 기대치maintenance-and-ci.md — 테스트가 간헐적으로 실패하면 불안정 테스트 절차 참조
티켓 컨텍스트 (기본 경로)
티켓 키가 제공된 경우:
.qabuddy.json 확인 (파일이 있으면) — 컨텍스트 소스와 팀 모드를 읽습니다.
contextSource: "spec" → 질문 전에 워크스페이스에서 스펙 파일을 먼저 검색contextSource: "chat" → Jira를 건너뛰고 SDT에게 직접 컨텍스트 요청contextSource: "jira" 또는 설정 없음 → 기본 동작
- 티켓 컨텍스트를 가져옵니다 (Jira MCP가 있으면 사용, 없으면 SDT에게 제공하거나 파일을 지정하도록 요청): 요약, 설명, AC, 상태, 상위 에픽, 연결된 버그
- 지식 베이스(KB)에서 로드합니다:
- 테스트 케이스:
features-kb/features/{EPIC-KEY}/test-cases/{TICKET-KEY}.md
- 추적성 매핑:
features-kb/features/{EPIC-KEY}/test-cases/{TICKET-KEY}-mapping.json
- 테스트 계획:
features-kb/features/{EPIC-KEY}/test-plan.md
- 이전 QA 보고서:
features-kb/features/{EPIC-KEY}/qa-reports/
- 테스트 케이스가 없는 경우:
SDT에게 질문합니다: "{TICKET-KEY}에 대한 테스트 케이스가 없습니다.
/test-cases {TICKET-KEY}를 먼저 실행할까요, 아니면 AC 기반으로 바로 테스트할까요?"
티켓 없는 경우 (URL만 또는 브랜치 기반)
- 브랜치 이름에서 티켓 키를 추출합니다(예:
feature/PROJ-123-description). 찾으면 위와 같이 컨텍스트를 로드합니다
- 티켓 컨텍스트 없이 URL만 있는 경우: 탐색적 테스트를 진행하며, 기능 정상 동작, 콘솔 오류, 명확한 버그에 집중합니다 (AC 없이는 정식 PASS/FAIL 판정을 내리지 않습니다)
환경
- URL이 제공되면 그대로 사용합니다. 없으면 일반적인 포트(3000, 4000, 5173, 8080)를 시도합니다. 아무것도 찾지 못하면 SDT에게 확인합니다
플래그:
| 플래그 | 기본값 | 효과 |
|---|
--fix | off | 경미한 수정 모드 활성화 (CSS, 문구, 설정만 해당) |
--quick | off | P0 테스트 케이스만 실행, 탐색적 테스트 생략 |
--exhaustive | off | 모든 테스트 케이스 + 전체 탐색적 테스트 + 반응형 확인 |
출력 디렉터리 생성: mkdir -p .qa-reports/screenshots
2단계: 테스트 케이스 실행
KB의 테스트 케이스를 우선순위 순서로 실행합니다 (P0부터).
테스트 케이스별 절차:
- KB에서 테스트 케이스를 읽습니다 (사전 조건, 단계, 기대 결과)
- 사전 조건을 설정합니다 (페이지 이동, 상태 준비)
- 브라우저에서 각 단계를 실행합니다
- 증거를 수집합니다: 마지막 단계 후 스크린샷, 예상과 다른 동작의 스크린샷, 각 상호작용 후 콘솔 오류 확인
- 결과를 기록합니다:
### TC-{NNN}: {제목}
**Priority:** P0 | P1 | P2
**AC:** {TICKET-KEY}의 #{N}
**Result:** PASS | FAIL | BLOCKED | SKIPPED
**Evidence:** {스크린샷 경로}
**Console:** {정상 | 오류 발견}
**Notes:** {FAIL 또는 BLOCKED인 경우 세부사항}
결과 정의:
| Result | 의미 |
|---|
| PASS | 기대 결과와 실제 결과가 일치 |
| FAIL | 실제 결과가 기대와 다름 |
| BLOCKED | 실행 불가 — 사전 조건/환경/의존성 문제 |
| SKIPPED | 사유를 명시하고 의도적으로 건너뜀 |
정식 테스트 케이스 이후 (--quick이 아닌 경우):
- 테스트 케이스에서 다루지 않은 엣지 케이스 (빈 상태, 오류 상태, 잘못된 입력)
- 영향을 받을 수 있는 인접 기능
- 관련 페이지 전체의 콘솔 확인
- UI 기능인 경우 반응형 확인 (모바일 뷰포트 375x812)
3단계: AC 검증
추적성 매핑을 사용하여 테스트 결과를 인수 조건에 매핑합니다.
티켓의 각 AC에 대해:
| # | 인수 조건 | 테스트 케이스 | 결과 | 판정 |
|---|
| 1 | {AC 내용} | TC-001, TC-002 | PASS, PASS | PASS |
판정 규칙:
- PASS — 관련 테스트 케이스가 모두 통과
- FAIL — 관련 테스트 케이스 중 하나라도 실패
- PARTIALLY TESTED — 일부 통과, 일부 BLOCKED/SKIPPED
- NOT TESTED — 이 AC에 대한 테스트 케이스가 없음 (커버리지 갭으로 표시)
- BLOCKED — 환경 또는 의존성 문제로 검증 불가
티켓 수준 판정:
- 모든 AC PASS → 티켓이 다음 단계로 진행 가능
- AC 중 FAIL 있음 → 버그 등록 필요, 티켓은 테스트 중 상태 유지
- AC 중 NOT TESTED 있음 → 커버리지 갭,
/test-cases 실행을 권장
4단계: 버그 등록
FAIL 결과마다 Jira 버그를 작성합니다.
버그 구조:
- Summary:
[TICKET-KEY] {실패에 대한 간단한 설명}
- 재현 단계: 번호 매김, URL 이동부터 시작
- 기대 결과: AC #{N} 기준
- 실제 결과: 실제로 발생한 현상
- 증거: 스크린샷, 콘솔 오류, 테스트 케이스 참조
- Severity / Priority / AC / 환경
등록 워크플로우:
- 중복 확인 — 이 티켓에 연결된 기존 버그를 검색합니다. 동일한 버그가 있으면 "{BUG-KEY}의 중복"으로 표시합니다
- SDT에게 제시 — 작성한 버그를 보여주고 심각도 확인을 요청합니다. SDT 승인 없이 절대 등록하지 마세요
- 버그 등록:
- Jira MCP 있는 경우: 이슈를 생성하고 상위 티켓에 연결합니다
- Jira 없는 경우: 위의 버그 템플릿을 사용하여
features-kb/features/{EPIC-KEY}/bugs/{BUG-NNN}.md에 작성합니다. SDT가 직접 프로젝트 관리 도구에 등록합니다.
- 보고서에 기록 — 등록된 버그 키(또는 파일 경로)를 QA 보고서에 기록합니다
5단계: 경미한 수정 모드 (--fix인 경우만)
SDT가 --fix를 전달한 경우에만 실행합니다. 그 외에는 이 단계를 건너뜁니다.
대상 이슈: 다음 카테고리의 Minor 또는 Trivial 심각도만 해당:
- CSS/스타일링 (여백, 정렬, 색상)
- 문구/텍스트 (오타, 문구 수정)
- 설정 (피처 플래그, 환경 변수)
수정 루프:
- 소스 파일을 찾습니다
- 이슈를 해결하는 최소한의 변경을 적용합니다
- 원자적 커밋:
fix: {내용} — QA for {TICKET-KEY}, TC-{NNN}
- 브라우저에서 다시 테스트하고 수정 후 스크린샷을 캡처합니다
- 인접 페이지에서 콘솔을 빠르게 확인합니다
Medium 이상 심각도는 수정하지 마세요 — 개발팀에 Jira 버그로 등록합니다.
세션당 최대 10건의 경미한 수정. 나머지는 버그로 등록합니다.
6단계: 자체 검증
보고서를 생성하기 전에 다음을 확인합니다:
- KB의 모든 테스트 케이스를 실행했거나, 건너뛴 사유가 문서화되어 있는지
- 티켓의 모든 AC에 판정이 있는지 (누락 없이)
- 각 버그에 구체적인 재현 단계, 명확한 기대-실제 결과 비교, 올바른 심각도, 스크린샷이 있는지
- 기존 연결된 이슈와 중복되는 버그를 등록하지 않았는지
- 탐색적 테스트 발견 사항이 문서화되고 필요시 등록되었는지
- 형식 확인: 보고서에 AC 테이블, 실행 요약, 등록된 버그, 판정, 다음 단계가 포함되어 있는지
누락된 항목을 보완합니다. 한 번만 확인하고 반복하지 않습니다.
7단계: 보고서 작성 및 KB 업데이트
QA 보고서
.qa-reports/qa-report-{TICKET-KEY}-{YYYY-MM-DD}.md와
features-kb/features/{EPIC-KEY}/qa-reports/{TICKET-KEY}-{YYYY-MM-DD}.md에 작성합니다:
# QA 보고서: {TICKET-KEY}
**Ticket:** {TICKET-KEY} — {제목}
**Epic:** {EPIC-KEY}
**Date:** {YYYY-MM-DD}
**SDT:** {사용자 또는 TBD}
**URL:** {대상}
**Mode:** {standard | quick | exhaustive} {+ fix (활성화된 경우)}
## AC 검증
| # | 인수 조건 | 테스트 케이스 | Result | Evidence |
|---|---------------------|-----------|--------|----------|
## 테스트 실행 요약
| Priority | 전체 | Pass | Fail | Blocked | Skipped |
|----------|-------|------|------|---------|---------|
## 등록된 버그
| Bug Key | Summary | Severity | AC | Status |
|---------|---------|----------|----|--------|
## 탐색적 테스트 발견 사항
## 적용된 수정 (--fix 모드인 경우)
| 수정 내용 | 파일 | 커밋 | 검증 여부 |
|-----|-------|--------|----------|
## 티켓 판정
**{PASS | FAIL | BLOCKED}**
{AC 통과 수, 버그 참조, 권장 사항을 포함한 한 줄 요약}
## 다음 단계
KB 업데이트
features-kb/features/{EPIC-KEY}/test-cases/{TICKET-KEY}.md에서 테스트 케이스 상태를 업데이트합니다 — 각 케이스에 날짜와 함께 통과/실패/차단 표시- 추적성 매핑을 업데이트합니다 — AC별 커버리지 상태 설정
- QA 보고서를 KB에 저장하여 sprint-status에서 집계할 수 있도록 합니다
Jira 업데이트
SDT가 승인하면 Jira 티켓에 요약 코멘트를 게시합니다:
QA 완료 {YYYY-MM-DD}.
- AC: {N}/{전체} 통과
- 등록된 버그: {BUG-KEY, BUG-KEY}
- 판정: {PASS | FAIL | BLOCKED}
- 전체 보고서: {경로}
Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
Summary: {한 줄 요약}
다음 단계: {SDT가 다음에 해야 할 작업, 또는 "없음"}
