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 redactcredentials/tokens/PII before saving any screenshot.
Phase 1: Smoke Test
Phase 2: Interaction Test
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__*
Pair with /canary-watch for post-deploy monitoring.