browser-qa

Topics in the source

• Browser QA — Automated Visual Testing & Interaction
• When to Use
• How It Works
• Safety first — blast radius (run read-only by default)
• Phase 1: Smoke Test
• Phase 2: Interaction Test
• Phase 3: Visual Regression
• Phase 4: Accessibility

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 Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to interact with live pages like a real user. 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. 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. Works with any browser MCP: mChildclaude-in-chrome tools (preferred — uses your actual Chrome) Playwright via mcpbrowserbase Direct Puppeteer scripts Pair with /canary-watch for post-deploy monitoring.