Imported from BogdanPanait92/Selenium-learning (
.grok/skills/visual-testing/SKILL.md). Install upstream withnpx skills add BogdanPanait92/Selenium-learning --skill visual-testing. Copyright stays with the author.
Visual Regression Testing Skill (Senior Level)
Visual testing is one of the highest maintenance-cost testing techniques when done poorly, and extremely valuable when done with discipline.
The Fundamental Question
Before recommending visual testing, always ask:
"What is the actual business risk if the UI looks slightly wrong in production?"
Many teams add visual testing because it sounds good, then spend more time maintaining baselines than the value it provides.
Tool Comparison (2026)
| Tool | Type | Best For | Maintenance Cost | Price Model | Recommendation |
|---|---|---|---|---|---|
| Playwright native | Open source | Simple needs, small surfaces | Medium | Free | Good starting point |
| Percy | SaaS | Serious visual testing | Medium | Paid (per snapshot) | Strong for teams that need it |
| Chromatic | SaaS + Storybook | Design systems & component libs | Low-Medium | Paid | Excellent for component-heavy teams |
| Applitools | AI-powered SaaS | Complex UIs, self-healing | Lower | Paid | Use when scale justifies cost |
| BackstopJS | Open source | Simple static sites | High | Free | Generally avoid |
When Visual Testing Makes Sense
Good candidates:
- Design systems and component libraries (Chromatic shines here)
- Products where visual consistency is critical (branding-heavy sites, dashboards with precise layouts)
- Teams with dedicated design + engineering collaboration
- High-traffic marketing pages
Poor candidates:
- Rapidly changing UIs / early-stage products
- Heavy dynamic content (dashboards with live data, personalized content)
- Teams without bandwidth to review visual diffs regularly
- Projects where functional testing already covers the main risks
Critical Success Patterns
1. Aggressive Masking & Stabilization
Never snapshot areas with:
- Dynamic dates, times, prices, user-generated content
- Third-party widgets (maps, calendars, ads)
- Animations
- Random content
Use Playwright's mask option or tool-specific masking extensively.
2. Start Narrow
Begin with a small number of high-value, relatively stable pages/components. Expand only after the process is working smoothly.
3. Review Discipline
- Someone must actually review the visual diffs (ideally the right person — designer or frontend dev).
- Set a policy: "If no one reviews within X time, the build fails or the baseline is auto-accepted with a note."
4. Threshold Strategy
- Use pixel or layout thresholds thoughtfully (not zero, not 50%).
- Different thresholds for different areas (strict on branding, looser on content areas).
Playwright Native Visual Testing Example
await expect(page).toHaveScreenshot('dashboard.png', {
mask: [page.locator('.user-avatar'), page.locator('.live-timestamp')],
maxDiffPixels: 100,
threshold: 0.2,
});
Maintenance Reality
Visual testing suites tend to degrade over time unless actively maintained. Common failure modes:
- Too many snapshots → review fatigue → people stop caring
- Baselines updated without proper review
- Flaky visual tests due to fonts, rendering differences, or CI environment drift
- "It looks different but it's fine" → baselines keep getting updated for the wrong reasons
Recommendation Framework
- Small team / fast-moving product → Start with Playwright native on 5-10 critical stable views. Re-evaluate in 3 months.
- Design system or component library → Use Chromatic (best-in-class experience).
- High visual quality bar + budget → Consider Percy or Applitools.
- No dedicated reviewer bandwidth → Strongly reconsider doing visual testing at all.
Visual testing has one of the highest "it seemed like a good idea" failure rates in QA. Be brutally honest about whether the team will actually maintain it.
Always include the expected ongoing cost (review time + maintenance) in any recommendation.