| name | verify-fix |
| version | 0.3.0 |
| description | 개발자가 수정한 버그를 재테스트합니다. Jira에서 원본 버그를 가져오고,
브라우저에서 재현 단계를 다시 실행하며, 회귀 여부를 확인하고, 버그 상태를
업데이트합니다. 티켓이 Done으로 넘어가기 전 SDT 워크플로우의 마지막 단계입니다.
사용 시점: "수정 검증", "재테스트", "이거 고쳐졌어?", "BUG-123 확인", "BUG-123 검증".
사용하지 않는 경우: 최초 QA 실행(/qa 사용), 새 버그 등록, 기능을 처음 테스트할 때.
|
| tool-groups | ["bash","read","write","edit","glob","grep","ask","jira","browser"] |
| preamble-tier | 2 |
/verify-fix: 버그 수정 재테스트 및 검증
SDT 파트너로서 개발자의 버그 수정이 정상 동작하는지 검증합니다.
Jira에서 원본 버그를 가져오고, 브라우저에서 재현 단계를 다시 실행하며,
관련 기능의 회귀 여부를 확인하고, 결과에 따라 버그 상태를 업데이트합니다.
이 스킬은 코드를 수정하지 않습니다. 다른 사람이 수정한 내용을 검증합니다.
제약 조건
- 원본 재현 단계를 정확히 따르세요. 임의로 변경하지 마세요. 단계가 불명확하면 SDT나 개발자에게 확인하세요.
- 코드를 수정하지 마세요. 수정이 동작하지 않으면 개발자에게 돌려보내세요.
- 항상 회귀 여부를 확인하세요. 다른 곳을 망가뜨리는 수정은 수정이 아닙니다.
- 수정 전후 증거를 확보하세요. 원본 스크린샷이 없으면 그 사실을 기록하세요 — 비교할 수 없는 상태에서 비교했다고 주장하지 마세요.
- SDT가 Jira 변경을 승인합니다. SDT 확인 없이 버그 상태를 전환하거나 회귀 버그를 등록하지 마세요.
- 회귀 테스트 부재를 표시하세요. 섹션 9.5에 따라, 검증된 수정에는 재발을 방지하는 테스트가 있어야 합니다.
- 반드시 브라우저를 사용하세요. 코드만 읽고 검증하지 마세요.
1단계: 버그 컨텍스트 로드
입력: 사용자가 버그 키(예: BUG-123)를 제공하거나 "PROJ-789 수정 검증해줘"라고 요청합니다.
방법론 참조 문서를 로드합니다 ({{REFERENCE_PATH}}/playbook/):
defect-lifecycle.md — 버그 상태, SLA 기대치, 회귀 테스트 요구사항
버그 컨텍스트 가져오기 (Jira MCP가 있으면 사용, 없으면 SDT에게 요청)
.qabuddy.json 확인 (파일이 있으면) — 컨텍스트 소스와 팀 모드를 읽습니다.
contextSource: "spec" → 질문 전에 워크스페이스에서 스펙 파일을 먼저 검색contextSource: "chat" → Jira를 건너뛰고 SDT에게 직접 컨텍스트 요청contextSource: "jira" 또는 설정 없음 → 기본 동작
- 버그 티켓: 요약, 설명, 재현 단계, 심각도, 우선순위, 상태, 연결된 상위 티켓, 수정 버전 / PR 링크, 보고자, 담당자
- 상태가 "Fixed" 또는 그에 해당하는 상태가 아니면 경고합니다: "이 버그가 아직 수정 완료로 표시되지 않았습니다. 그래도 검증할까요?"
- 원본 QA 보고서 (
/qa로 버그를 등록한 경우):
features-kb/features/{EPIC-KEY}/qa-reports/에서 찾습니다- 원본 실패 테스트 케이스와 스크린샷("수정 전")을 로드합니다
- 연결된 PR / 커밋: Jira 코멘트에서 PR 링크를 확인하고,
git log에서 버그 키를 참조하는 커밋을 확인합니다
수정 배포 확인
테스트 전에 수정 사항이 접근 가능한지 확인합니다:
- 로컬호스트: 수정 브랜치가 체크아웃 또는 머지되었는지 확인
- 스테이징: 배포에 수정 사항이 포함되었는지 확인 (커밋 해시, 배포 로그, 또는 SDT에게 확인)
배포되지 않은 경우 BLOCKED로 보고합니다: "{BUG-KEY}의 수정 사항이 {URL}에 배포되지 않은 것으로 보입니다."
2단계: 재현 단계 재실행
버그 티켓에 기록된 원본 재현 단계를 정확히 따릅니다.
각 단계별 절차:
- 브라우저에서 실행합니다
- 실제와 기대를 비교합니다 (기대 = 원래 버그가 아닌 수정된 동작)
- 스크린샷을 캡처합니다 ("수정 후" 증거)
- 콘솔에서 새로운 오류를 확인합니다
결과를 기록합니다:
### 재현 시도
**Bug:** {BUG-KEY}
**티켓의 재현 단계:** 정확히 따름 / 수정함 (사유 설명)
| 단계 | 수행 내용 | 기대 결과 (수정 후) | 실제 결과 | 일치 여부 |
|------|--------|------------------|--------|--------|
**스크린샷 (수정 전 — 원본 보고서):** {경로}
**스크린샷 (수정 후 — 이번 검증):** {경로}
**Console:** {정상 / 오류}
수정이 동작하지 않는 경우:
- 버그가 지속되는 증거를 캡처합니다
- 원본과의 차이를 기록합니다 (동일한 현상? 부분 수정? 새로운 현상?)
- 직접 수정하지 마세요
3단계: 회귀 확인
3.1 관련 테스트 케이스 재실행
원본 버그가 KB 테스트 케이스가 있는 티켓에 연결된 경우:
- 버그가 등록된 AC에 대한 테스트 케이스를 다시 실행합니다
- 같은 티켓의 인접 AC에 대한 테스트 케이스를 다시 실행합니다
- 모두 PASS여야 합니다
3.2 인접 페이지 확인
- 관련 페이지 2-3개를 이동하며 확인합니다
- 시각적 깨짐, 콘솔 오류, 동작 불량을 점검합니다
- 동일한 사용자 플로우와 업스트림/다운스트림 각 한 단계에 집중합니다
3.3 회귀 테스트 존재 여부
섹션 9.5에 따라, 검증된 수정에는 회귀 테스트가 있어야 합니다:
- 개발자가 이 버그에 대한 테스트(Playwright 또는 단위 테스트)를 추가했는지 확인합니다
- 없는 경우: "{BUG-KEY}에 대한 회귀 테스트가 없습니다.
/test-cases {TICKET-KEY} --update로 추가하는 것을 권장합니다."
4단계: 자체 검증
판정을 내리기 전에 다음을 확인합니다:
- 재현 단계를 정확히 따랐는지 (변경한 경우 사유가 문서화되었는지)
- 수정 전후 스크린샷이 있는지 (없으면 그 사실을 기록했는지)
- 회귀 확인이 정확한 버그뿐 아니라 관련 기능을 포함했는지
- 수정 검증과 회귀 확인 후 콘솔을 확인했는지
- 형식 확인: 보고서에 판정, 재현 테이블, 회귀 테이블, 다음 단계가 포함되어 있는지
누락된 항목을 보완합니다. 한 번만 확인합니다.
5단계: 판정 및 업데이트
판정
| 판정 | 의미 | Jira 조치 |
|---|
| VERIFIED | 수정이 동작하며 회귀 없음 | 버그를 Verified/Closed로 전환 |
| FAILED | 버그가 여전히 재현됨 | 새로운 증거와 함께 버그를 Open으로 되돌림 |
| REGRESSION | 수정은 동작하나 다른 곳이 깨짐 | 원본은 Verified로 유지하고 회귀에 대해 새 버그 등록 |
검증 보고서
다음 두 위치에 작성합니다:
features-kb/features/{EPIC-KEY}/qa-reports/{BUG-KEY}-verify-{YYYY-MM-DD}.md.qa-reports/{BUG-KEY}-verify-{YYYY-MM-DD}.md
# 수정 검증: {BUG-KEY}
**Bug:** {BUG-KEY} — {요약}
**상위 티켓:** {TICKET-KEY}
**수정자:** {담당자 / PR 링크}
**검증일:** {YYYY-MM-DD}
**URL:** {대상}
## 판정: {VERIFIED | FAILED | REGRESSION}
{한 줄 요약}
## 재현 결과
| 단계 | 수행 내용 | 기대 결과 | 실제 결과 | 일치 여부 |
|------|--------|----------|--------|--------|
**수정 전:** {원본 보고서의 스크린샷}
**수정 후:** {이번 검증의 스크린샷}
## 회귀 확인
| 확인 항목 | 결과 | 비고 |
|-------|--------|-------|
| 관련 테스트 케이스 | {N}/{N} 통과 | |
| 인접 페이지 | 정상 / 이슈 있음 | |
| Console | 정상 / 오류 | |
| 회귀 테스트 존재 | 있음 / 없음 | |
## 다음 단계
**Status:** DONE | DONE_WITH_CONCERNS | BLOCKED
**Summary:** {한 줄 요약}
**다음 단계:** {다음에 할 일, 또는 "없음"}
상태 업데이트
변경 전에 SDT에게 제시합니다:
Jira MCP가 있는 경우:
- VERIFIED: Verified/Closed로 전환하고, 수정 확인 및 회귀 없음을 코멘트로 남깁니다.
- FAILED: Open으로 되돌리고, 새로운 재현 증거를 코멘트로 남깁니다.
- REGRESSION: 원본은 Verified로 유지하고,
/qa 버그 등록 워크플로우를 통해 새 버그를 등록합니다.
Jira가 없는 경우:
features-kb/features/{EPIC-KEY}/bugs/의 버그 파일에 판정을 업데이트합니다.- REGRESSION인 경우: 새 버그 파일을 생성합니다. SDT가 직접 관리 도구에 등록합니다.
일괄 처리 모드
SDT가 "PROJ-789 수정 검증해줘" (여러 버그가 연결된 상위 티켓)라고 요청한 경우:
- Fixed 상태의 연결된 버그를 모두 가져옵니다 (Jira에서 또는 SDT에게 목록 요청)
- 각 버그를 순서대로 검증합니다
- 요약을 제공합니다:
## 수정 검증 요약: {TICKET-KEY}
| Bug | Summary | 판정 | 회귀 여부 | 비고 |
|-----|---------|---------|-------------|-------|
**전체 결과:** {N}/{전체} 검증 완료. {N}건 여전히 실패. {N}건 회귀 등록.
