--- name: qa description: Audits a feature that has shipped to a dev or staging server against the plan of record — spec entries and the Figma design. One mode stops once the checklist is drawn; the other clicks through the browser and files a defect report. Defects are written as reproduction steps, expected, actual, and evidence (request results, screens) so they can be handed to engineering as they are. Triggers - "/fig:qa", "QA this", "check what is on the dev server", "file the defects", "QA 해줘", "개발서버 확인해줘", "결함 정리해줘". allowed-tools: AskUserQuestion, mcp__claude_ai_Notion__notion-fetch, mcp__claude_ai_Notion__notion-search, mcp__claude_ai_Notion__notion-query-data-sources, mcp__claude_ai_Slack__slack_read_thread, mcp__claude_ai_Slack__slack_read_channel, mcp__plugin_figma_figma__get_screenshot, mcp__plugin_figma_figma__get_metadata, mcp__claude-in-chrome__tabs_context_mcp, mcp__claude-in-chrome__tabs_create_mcp, mcp__claude-in-chrome__navigate, mcp__claude-in-chrome__browser_batch, mcp__claude-in-chrome__computer, mcp__claude-in-chrome__find, mcp__claude-in-chrome__read_page, mcp__claude-in-chrome__get_page_text, mcp__claude-in-chrome__read_console_messages, mcp__claude-in-chrome__read_network_requests --- # qa — 기준선 대조 QA (체크리스트 → 검증 → 결함 리포트) 기능이 서버에 올라왔을 때, **기획 기준과 대조해** 무엇이 어긋났는지 찾아 개발이 바로 고칠 수 있는 형태로 넘긴다. **핵심 전제**: 기준선 없는 판정은 하지 않는다. "이상해 보인다"가 아니라 **"어느 문서의 어느 규칙에 어긋난다"**로 쓴다. 기준이 없는 항목은 결함이 아니라 `확인 필요`다. ## When to invoke - 개발·스테이징 서버 반영 공지를 받고 동작을 봐야 할 때 - 보고된 결함을 재현·확인해야 할 때 - 배포 전 기획 대비 구현 누락을 훑어야 할 때 - 검증 없이 **체크리스트만** 필요할 때(`baseline` 모드) ## When NOT to invoke - 시안 자체의 구조·네이밍 검수 → `/fig:lint` - 시안과 코드의 차이 반영 → `/fig:code` - 문서·메시지 리뷰 → 이 스킬이 아니다 - 결함을 일감으로 등록 → 쓰는 일감 도구로. 이 스킬은 리포트까지만 낸다 ## Inputs - `source` (필수): 요청 출처 — 스레드 링크, 페이지, 또는 구두 요청 내용 - `target` (필수): 검증 대상 화면·기능 이름 - `mode` (선택): `baseline`(체크리스트까지) / `full`(검증·리포트까지). 생략하면 묻는다 - `env` (선택): 접속 주소, 계정 범위, 테스트 대상 데이터 범위(지점·조직 등). 이름만 주면 `qa.environments` 에서 주소를 찾는다 ## 모드 baseline 1~3단계만. 체크리스트를 내고 종료 — 남이 돌릴 때, 검증 전 합의가 필요할 때 full 1~7단계 전부. 브라우저로 직접 검증하고 결함 리포트까지 `full`이라도 3단계 체크리스트는 **검증 착수 전에 먼저 보여준다**. 무엇을 볼지 합의하지 않은 채 누르기 시작하면 범위가 흐른다. --- ## 1. 대상 확정 (읽기, 컨펌 없이) 출처를 읽어 다음을 뽑는다. 추측하지 않는다. - 무엇이 올라왔는지 / 어디까지가 이번 범위인지 - **이미 보고된 결함** — 있으면 최우선 재현 대상이다 - 요청자가 특별히 확인해 달라고 지목한 것 - 제외 지시(보지 말라고 한 범위) 출처에 없어 모르는 것은 `TBD`로 남기고, 검증 결과에 영향을 주는 것만 질문한다. ## 2. 기준선 수집 (읽기) 판정 근거가 될 문서를 모은다. **내부 자산을 먼저** 찾는다. 어디를 볼지는 `qa.baseline` 이 정하고, `null` 인 항목은 건너뛴다. | 출처 | 뽑을 것 | |---|---| | PRD 기능·정책 행 | 세부 동작(Given·When·Then), 상태·케이스, 룰·예외 | | 시안 | 화면 구성, 상태 변형, 문구 | | 기존 일감 | 과거 결정·번복 이력, 미결정 항목 | | 요청 출처 | 이번 차수에 새로 요구된 것 | - 기능·정책은 **도메인 단위로 전수**를 뽑는다. 몇 개만 보면 검증 항목이 샌다. - `보관`·`폐기` 상태 행도 함께 본다 — **폐기된 기능이 화면에 남아 있는 것**이 흔한 결함이다. - 상태가 `확정`이 아닌 행은 기준선으로 쓰되 리포트에 `기준 미확정`을 붙인다. ## 3. 체크리스트 생성 화면·기능 단위로 묶고, 각 항목은 **눌러서 참/거짓이 판별되는 문장**으로 쓴다. ① [화면명] □ [동작] — 기준: PRD 세부 동작 □ [상태] — 빈 상태 / 로딩 / 에러 / 권한 □ [룰] — 값 제약·상속·연동 규칙 ← 보고된 결함은 해당 위치에 표시해 재현 대상임을 드러낸다 각 화면마다 아래 4종을 빠뜨리지 않는다. - **정상 동작** — 세부 동작표 그대로 - **상태·케이스** — 빈 상태·로딩·에러·권한·페이지네이션 - **룰·예외** — 상속·고정·연동처럼 "값이 어디서 오는가" 규칙 - **되돌아오기** — 저장·수정 후 목록·다른 화면에 제대로 반영되는가 계정·데이터가 없어 못 보는 항목은 여기서 미리 `미검증 예정`으로 분리한다. **`baseline` 모드는 여기서 종료.** ## 4. 접속 준비 - 접속 주소·대상 데이터 범위를 확인한다. 보지 말라고 한 범위는 건드리지 않는다. - **로그인·인증 정보는 절대 대신 입력하지 않는다.** 화면까지 띄워 달라고 요청하고 이어받는다. - 검증 시작 전 현재 상태(총 건수, 대상 항목의 값)를 기록해 둔다 — 저장 전후 대조와 원복의 기준이 된다. ## 5. 검증 실행 체크리스트 순서대로 돌린다. 클릭·입력·대기·캡처는 한 번에 묶어 왕복을 줄인다. ### 데이터 취급 원칙 - **생성·삭제는 하지 않는다.** 모달 노출·필수값 가드·취소까지만 본다. `qa.allow_write` 가 참이어도 꼭 필요할 때만, 먼저 확인받고 한다. - 값을 바꿨으면 **저장 전에 원복**한다. 저장까지 해야 하는 검증은 원복 경로가 있는지 먼저 확인한다. - 원복하지 못한 변경은 그 자리에서 기록해 리포트에 남긴다. ### 결함을 놓치지 않는 판별법 실전에서 반복해 걸린 것들이다. 체크리스트에 없어도 항상 돌린다. | 검사 | 방법 | 잡히는 것 | |---|---|---| | **진입 직후 첫 액션** | 새로고침 → 아무 조작 없이 바로 탭 전환·필터·검색 | 첫 클릭이 통째로 먹지 않는 부류. 두 번째부터 정상이라 수동 QA에서 잘 빠진다 | | **경로 교차 대조** | 같은 데이터를 다른 경로로 조회(필터 vs 검색 vs 상세) | 특정 조회 경로에서만 값·이미지가 비는 결함 | | **건수 대조** | 저장·토글 전후 총 건수 비교 | 목록에서 항목이 빠지거나 늘어나는 유실·중복 | | **왕복 반영** | 상세에서 바꾸고 목록으로 돌아와 확인 | 저장은 되는데 목록에 안 붙는 부류 | | **실패 근거** | 에러가 뜨면 네트워크 요청·콘솔을 함께 확보 | 어느 요청이 몇 번으로 실패했는지 — 개발 전달 근거 | | **목록 간 정합** | 같은 항목을 다루는 두 화면의 목록을 대조 | 한쪽에만 있는 항목, 관리 목록에 없는 값이 다른 곳에서 선택되는 문제 | | **입력 가드** | 고정이어야 할 값에 실제로 입력해 본다 | 수정 불가 규칙이 화면에서 안 지켜지는 것 | ### 재현·판정 규칙 - **1회 실패는 결함으로 확정하지 않는다.** 최소 2회, 조건을 바꿔 재현한다. - 재현되지 않으면 `간헐`로 적고 관측된 조건을 함께 쓴다. 지우지 않는다. - 데이터 탓일 수 있는 것(값 미등록 등)은 다른 경로에서 같은 항목을 확인해 **구현 문제와 데이터 문제를 가른다.** - 기준선에 없는 차이는 결함이 아니라 `확인 필요`다. 시안·문서와 다르면 어느 쪽이 최신인지 먼저 묻는다. - 오탐 주의: 상태 의존 검증은 **그 상태를 실제로 만든 뒤** 확인한다(예: 이탈 경고는 값을 바꾼 채로 나가야 검증된다). ## 6. 결함 리포트 보고된 것과 새로 찾은 것을 **나눠서** 낸다. 요청자는 자기가 올린 건이 어떻게 됐는지부터 본다. [보고된 건] 각 항목마다 재현 여부 + 관측 내용 [신규] 심각도 순 심각도는 결과의 크기로 가른다. 라벨은 `qa.severity` 를 쓴다 — 조직마다 부르는 이름이 다르니 그곳 버그 트래커 표현을 그대로 따른다. 1단계 데이터 유실·복구 불가·업무 중단 2단계 핵심 동작 불가·기준 위반 3단계 일부 정보 누락·목록 불일치 4단계 문구·아이콘·식별성 ### 칸을 이슈 양식에 맞춘다 결함은 나중에 이슈로 올라간다. **처음 적을 때부터 이슈 양식의 칸과 1:1로 적어**, 옮길 때 본문이 그대로 채워지게 한다. 칸은 `qa.report_fields` 를 쓰고, 설정이 없으면 아래를 쓴다. 회차 공통은 리포트 머리에 **한 번만** 적는다 — 결함마다 반복하지 않는다. 프로젝트 / 버전·빌드 환경 — 서버(dev·staging·운영) · 계정 권한 · 데이터 범위 기준 문서 — 기능·정책 행 · 시안 · 스펙 결함 한 건: {번호} · {요약 — 명사형 한 줄} · 심각도: `qa.severity` 중 하나 · 빈도: `qa.frequency` 중 하나 · 재현: 1) … 2) … 3) … · 기대: … (기준: 어느 문서의 무엇) · 실제: … · 증거: 요청 결과 · 화면 · 건수 변화 빈도를 빼지 않는다 — 간헐 결함을 "항상"으로 읽히게 두면 개발이 재현에 시간을 버린다. 판정 문장은 기획 표현으로 쓰고, 요청 결과·코드 같은 개발 정보는 **증거 줄에만** 둔다. ## 7. 마무리에 반드시 적을 것 - **정상 확인** 목록 — 이상 없는 것도 적어야 커버리지가 보인다 - **미검증** 목록 + 사유(계정 없음·범위 제외·데이터 없음) - **남긴 변경** — 원복하지 못한 데이터와 그 경위 이 셋이 빠지면 "다 봤다"로 읽힌다. 안 본 것을 안 봤다고 적는 것이 리포트의 절반이다. --- ## 산출물 전달 리포트를 어디로 보낼지는 **묻고 정한다**(응답으로만 / 일감에 기록 / 회신 초안). 외부 쓰기는 미리보기 → "go" 이후에만 한다.