Playwright Visual Regression Test Plan Builder

Design a Playwright visual regression testing plan with screenshot scope, viewport coverage, stable fixtures, diff thresholds, CI gates, and triage rules.

Prompt Template

You are a senior frontend test engineer designing a Playwright visual regression suite for a real product. Build the plan for:

Application type: [SaaS dashboard, ecommerce site, mobile web app, marketing site, design system, internal tool]
Framework and stack: [Next.js, React, Vue, Svelte, Angular, Rails, Laravel, static HTML]
Current test setup: [Playwright installed, no tests, Storybook, unit tests, e2e tests, CI provider]
Critical screens: [routes, components, flows, dashboards, emails rendered in browser, modals]
Responsive targets: [desktop, tablet, mobile, high-density display, dark mode, reduced motion]
Dynamic content: [dates, charts, avatars, ads, animation, randomized data, third-party widgets]
Authentication and data fixtures: [seed account, mocked API, test database, fixture JSON, network stubs]
Design risk areas: [navigation, pricing cards, checkout, editor canvas, PDF preview, localization, long labels]
CI constraints: [runtime budget, parallel workers, browser matrix, artifact storage, branch previews]
Failure tolerance: [strict, warning-only, threshold per component, manual approval]
Team workflow: [PR review, design review, release gate, QA owner, flaky test triage]

Create:
1. Test scope matrix separating page screenshots, component screenshots, and flow checkpoints.
2. Viewport and theme coverage with the minimum set that catches layout risk.
3. Fixture strategy for freezing dates, seeded data, fonts, animations, network calls, and viewport size.
4. Playwright project configuration outline with snapshot paths and artifact retention.
5. Example test file structure and naming conventions.
6. Diff threshold policy with when to use strict, masked, clipped, or tolerant comparisons.
7. CI workflow for generating baselines, comparing PRs, uploading artifacts, and approving intentional changes.
8. Flake triage checklist for fonts, animations, anti-aliasing, network timing, scrollbars, and chart rendering.
9. Rollout plan from smoke coverage to critical-path coverage to design-system coverage.
10. Maintenance rules for snapshot reviews, cleanup, and ownership.

Prefer stable deterministic tests over broad screenshot spam. Flag places where a functional assertion is better than a visual snapshot.

Example Output

Initial Screenshot Matrix

| Area | Route or Component | Viewports | Theme | Stabilizers | Gate |

|---|---|---|---|---|---|

| Pricing | /pricing | 390x844, 1440x900 | light/dark | Freeze plan data, disable animations | Required |

| Dashboard table | /app/reports | 1280x900 | light | Seed 12 rows, mock current date | Required |

| Toasts | Storybook story | 390x844 | light | Clip component, fixed message | Warning |

Example Policy

Use strict comparison for static marketing pages. Use masks for timestamps, avatars, and chart tooltips. Any baseline update needs a PR label plus reviewer confirmation that the diff is intentional.

Flake First Checks

Confirm fonts are loaded before screenshots, animations are disabled with reduced motion, API calls are mocked, and scrollbars are consistent across CI and local runs.

Tips for Best Results

  • 💡Start with the few screens where visual damage would block a release; broad snapshot suites become noisy fast.
  • 💡List every dynamic element so the plan can mask or stabilize it before CI creates false failures.
  • 💡Ask for both the rollout plan and the baseline approval workflow; the human process matters as much as the test code.