Communitygithub.com

DeanMcCoppin/browser-qa

배포 후 UI 검증을 실제 브라우저에서 수행합니다: 콘솔 및 네트워크 오류, Core Web Vitals 스모크 체크, 테스트 계정을 사용한 폼 및 인증 흐름, 375/768/1440px 해상도에서의 스크린샷과 베이스라인 비교, axe 접근성 검사. 최종 결과는 SHIP / SHIP WITH FIXES / DO NOT SHIP 중 하나로 반환됩니다. 스테이징이나 프리뷰 URL에 배포한 후, 프론트엔드 변경사항을 출시하기 전, 프론트엔드 PR을 리뷰할 때, 또는 실시간 페이지의 반응형 레이아웃과 접근성을 확인할 때 사용하세요.

browser-qa란 무엇인가요?

Browser QA는 배포 후 UI 검증을 실제 브라우저에서 자동화하는 AI 에이전트 스킬입니다. 프론트엔드 변경사항을 출시하기 전 스테이징 또는 프리뷰 URL에서 사용하며, 콘솔 및 네트워크 오류 검사, Core Web Vitals (LCP < 2.5s, CLS < 0.1, INP < 200ms) 측정, 테스트 계정을 이용한 폼 및 인증 흐름 테스트, 375/768/1440px 세 가지 뷰포트에서의 시각적 회귀 테스트, axe-core 기반 WCAG 2.2 AA 접근성 검사를 포함합니다. 안전성을 최우선으로 하여 기본적으로 읽기 전용(read-only) 모드로 실행되며, 프로덕션 URL에 대해 변경을 가하는 작업은 명시적 동의와 스테이징 URL이 있을 때만 허용합니다. 최종적으로 SHIP, SHIP WITH FIXES, DO NOT SHIP 중 하나의 판정을 내립니다. Claude in Chrome, Playwright MCP, 또는 순수 Playwright 스크립트와 통합되어 동작합니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/DeanMcCoppin/Skills/tree/main/plugins/code-audit/skills/browser-qa

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

Browser QA — 자동화된 시각적 테스트 및 상호작용

사용 시점

  • 스테이징/프리뷰에 기능을 배포한 후
  • 여러 페이지에서 UI 동작을 확인해야 할 때
  • 출시 전 — 레이아웃, 폼, 상호작용이 실제로 작동하는지 확인
  • 프론트엔드 코드를 건드리는 PR을 리뷰할 때
  • 접근성 감사 및 반응형 테스트

작동 방식

브라우저 자동화 MCP(Claude in Chrome, Playwright 또는 Puppeteer)를 사용하여 실제 사용자처럼 실시간 페이지와 상호작용합니다.

안전 우선 — 영향 범위 (기본적으로 읽기 전용 실행)

Browser QA는 실제 인증 및 실제 사용자 여정을 구동하므로 영향 범위를 명시적으로 처리합니다. 기본적으로 읽기 전용: 프로덕션 URL에 대해 변경을 가하는 여정(결제, 결제, 삭제, 대량 업데이트)을 절대 실행하지 마세요 — 명시적인 동의 및 스테이징/프리뷰 URL이 필요합니다. 시드된 테스트 자격 증명을 사용하고, 실제 프로덕션 로그인은 절대 사용하지 마세요. 스크린샷을 저장하기 전에 자격 증명/토큰/PII를 삭제하세요.

1단계: 스모크 테스트

1. 대상 URL로 이동
2. 콘솔 오류 확인 (노이즈 필터링: 분석, 타사)
3. 네트워크 요청에 4xx/5xx가 없는지 확인
4. 데스크톱 + 모바일 뷰포트에서 접힌 부분 위 스크린샷 촬영
5. Core Web Vitals 확인: LCP < 2.5초, CLS < 0.1, INP < 200ms
   (INP는 2024년 3월에 FID를 대체; 임계값은 web.dev 기준)

2단계: 상호작용 테스트

1. 모든 내비게이션 링크 클릭 — 끊긴 링크가 없는지 확인
2. 유효한 데이터로 폼 제출 — 성공 상태 확인
3. 유효하지 않은 데이터로 폼 제출 — 오류 상태 확인
4. 인증 흐름 테스트: 로그인 → 보호된 페이지 → 로그아웃 (테스트 자격 증명만 사용, 프로덕션 절대 사용 금지)
5. 중요한 사용자 여정 테스트 (결제, 온보딩, 검색)
   — 기본적으로 읽기 전용; 변경을 가하는 여정은 명시적 동의가 있는 경우에만 스테이징에서 실행
     (위 "안전 우선" 참조)

3단계: 시각적 회귀 테스트

1. 주요 페이지를 3가지 중단점(375px, 768px, 1440px)에서 스크린샷 촬영
2. 커밋된 베이스라인 스크린샷과 비교
   — 베이스라인이 없으면 INCONCLUSIVE(판정 불가)로 보고, 조용히 PASS하지 않음
3. 5px 이상의 레이아웃 이동, 누락된 요소, 오버플로우 플래그 지정
4. 해당하는 경우 다크 모드 확인

4단계: 접근성

1. 각 페이지에서 axe-core 또는 동등한 도구 실행
2. WCAG 2.2 AA 위반 플래그 지정 (대비, 레이블, 포커스 순서)
3. 키보드 내비게이션이 종단간 작동하는지 확인
4. 스크린 리더 랜드마크 확인

참고: axe-core는 자동으로 WCAG의 약 30–40%를 커버합니다. 깨끗한 실행은 필요 조건이지, 충분 조건이 아닙니다 — 키보드 내비게이션, 포커스 순서, 스크린 리더 통과는 여전히 수동 확인이 필요합니다. 자동화된 실행만으로 "접근 가능"이라고 보고하지 마세요.

출력 형식

## QA 보고서 — [URL] — [타임스탬프]

### 스모크 테스트
- 콘솔 오류: 치명적 0개, 경고 2개 (분석 노이즈)
- 네트워크: 모두 200/304, 실패 없음
- Core Web Vitals: LCP 1.2초 ✓, CLS 0.02 ✓, INP 89ms ✓

### 상호작용
- [✓] 내비게이션 링크: 12/12 작동
- [✗] 문의 양식: 유효하지 않은 이메일에 대한 오류 상태 누락
- [✓] 인증 흐름: 로그인/로그아웃 작동

### 시각적
- [✗] 히어로 섹션이 375px 뷰포트에서 오버플로우
- [✓] 다크 모드: 모든 페이지 일관됨

### 접근성
- AA 위반 2개: 히어로 이미지에 대체 텍스트 누락, 푸터 링크의 대비 낮음

### 판정: 수정 후 출시 (2개 이슈, 차단 항목 없음)
# 판정 ∈ 출시 / 수정 후 출시 / 출시 불가; 시각적 베이스라인이 없으면 INCONCLUSIVE(판정 불가) 사용

통합

세션이 보유한 브라우저 도구와 함께 작동합니다: Chrome 속 Claude (mcp__claude-in-chrome__*), Playwright MCP 서버, 또는 셸에서 실행되는 일반 Playwright 스크립트. 사용 가능한 도구가 없으면 그렇게 말하고 결과를 추측하는 대신 Playwright 스크립트를 제공하세요.

반복 가능한 확인을 위해 발견 사항을 e2e-testing을 사용하여 테스트로 전환하고, 접근성 심층 분석은 accessibility를 참조하세요.

관련 스킬