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 ```markdown ## 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.

[{"step":1,"action":"Prepare your test configuration. Gather the [WEBSITE_URL], [FEATURE_NAME], and list of [ELEMENTS_TO_TEST] (e.g., buttons, forms, modals). Specify the [BROWSER_TYPE] (e.g., Chrome, Firefox, Edge) and any [BREAKPOINTS] for responsive testing (e.g., 375px, 768px, 1024px).","tip":"Use browser dev tools to identify the exact selectors (e.g., #submit-button, .modal-header) for the elements you want to test. Save these in a JSON file for reuse."},{"step":2,"action":"Run the test using the prompt template. Paste the template into your AI tool (e.g., Claude, ChatGPT) and replace the placeholders with your specific values. For advanced users, include additional checks like [PERFORMANCE_METRICS] (e.g., page load time, Core Web Vitals) or [A11Y_SCAN] (e.g., axe-core violations).","tip":"For large sites, break the test into smaller chunks (e.g., test one feature per run) to avoid timeouts. Use tools like Playwright or Puppeteer for local execution if needed."},{"step":3,"action":"Review the AI-generated report. Focus on critical failures (e.g., broken functionality, visual regressions) and warnings (e.g., console errors, accessibility issues). Use the provided screenshots to debug issues.","tip":"Compare screenshots against baseline images (if available) using tools like Percy, Applitools, or simple image diff tools (e.g., ImageMagick)."},{"step":4,"action":"Take action on the results. Prioritize fixes based on severity (critical > visual > warnings). Update your test configuration to include new edge cases or regressions you discover.","tip":"Automate the test by integrating it into your CI/CD pipeline (e.g., GitHub Actions, GitLab CI) using tools like Playwright or Cypress. Schedule periodic runs (e.g., nightly) to catch regressions early."},{"step":5,"action":"Iterate and improve. Refine your test cases based on common failures or new features. Document recurring issues in your QA wiki to prevent future regressions.","tip":"Use the AI skill to generate regression test suites after major updates. For example, after deploying a new UI library, test all components that use it."}]