browser-qa

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

Phase 3: Visual Regression

Phase 4: Accessibility

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

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.