browser-qa

name browser-qa description Use this skill to automate visual testing and UI interaction verification using browser automation after deploying features. metadata {"origin":"ECC"} Browser QA — Automated Visual Testing & Interaction When to Use After deploying a feature to staging/preview When you need to verify UI behavior across pages Before shipping — confirm layouts, forms, interactions actually work When reviewing PRs that touch frontend code Accessibility audits and responsive testing How It Works Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to interact with live pages like a real user. Safety first — blast radius (run read-only by default) Browser QA drives real auth and real user journeys, so treat the blast radius explicitly. Default to read-only : never run a mutating journey (checkout, payment, delete, mass-update) against a production URL — require an explicit opt-in and a staging/preview URL. Use seeded test credentials , never real production logins, and redact credentials/tokens/PII before saving any screenshot. Phase 1: Smoke Test 1. Navigate to target URL 2. Check for console errors (filter noise: analytics, third-party) 3. Verify no 4xx/5xx in network requests 4. Screenshot above-the-fold on desktop + mobile viewport 5. Check Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms (INP replaced FID in March 2024; thresholds per web.dev) Phase 2: Interaction Test 1. Click every nav link — verify no dead links 2. Submit forms with valid data — verify success state 3. Submit forms with invalid data — verify error state 4. Test auth flow: login → protected page → logout (test creds only, never prod) 5. Test critical user journeys (checkout, onboarding, search) — read-only by default; only exercise mutating journeys against staging with explicit opt-in (see "Safety first" above) Phase 3: Visual Regression 1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px) 2. Compare against committed baseline screenshots — no baseline ⇒ report INCONCLUSIVE, never a silent PASS 3. Flag layout shifts > 5px, missing elements, overflow 4. Check dark mode if applicable Phase 4: Accessibility 1. Run axe-core or equivalent on each page 2. Flag WCAG 2.2 AA violations (contrast, labels, focus order) 3. Verify keyboard navigation works end-to-end 4. Check screen reader landmarks Note: axe-core automatically covers roughly 30–40% of WCAG. A clean run is necessary, not sufficient — keyboard nav, focus order, and a screen-reader pass still need a manual check. Don't report "accessible" from an automated pass alone. Output Format ## QA Report — [URL] — [timestamp] ### Smoke Test - Console errors: 0 critical, 2 warnings (analytics noise) - Network: all 200/304, no failures - Core Web Vitals: LCP 1.2s ✓, CLS 0.02 ✓, INP 89ms ✓ ### Interactions - [✓] Nav links: 12/12 working - [✗] Contact form: missing error state for invalid email - [✓] Auth flow: login/logout working ### Visual - [✗] Hero section overflows on 375px viewport - [✓] Dark mode: all pages consistent ### Accessibility - 2 AA violations: missing alt text on hero image, low contrast on footer links ### Verdict: SHIP WITH FIXES (2 issues, 0 blockers) # verdict ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; use INCONCLUSIVE if no visual baseline Integration Works with any browser MCP: mChild__claude-in-chrome__* tools (preferred — uses your actual Chrome) Playwright via mcp__browserbase__* Direct Puppeteer scripts Pair with /canary-watch for post-deploy monitoring.