The Problem: Screenshots Are Not Enough Visual regression testing almost always starts with screenshots, and that makes sense — a screenshot is easy to understand. If yesterday's page and today's don't match, something changed. For UI, that feels like exactly the signal you want. But a screenshot is only evidence. On its own, it can't tell you whether a change is expected, who owns it, or whether it should block a release. That's why so many screenshot-testing efforts start strong and slowly turn into noise nobody trusts. The trap It plays out the same way almost everywhere: 1. A team adds screenshot tests. The first failures are genuinely useful — real bugs, caught early. 2. More pages and states get added. Coverage grows. 3. Screenshots start failing for reasons that have nothing to do with the UI: a clock, an ad slot, an animation, unstable test data. 4. Engineers spend more time deciding whether to believe the test than fixing anything. 5. People start clicking "approve" without really looking. The gate still runs — but nobody believes it anymore. A quality gate only works when people trust both its failures and its passes. Once that trust is gone, adding more screenshots doesn't help. It makes the noise louder. The context a screenshot doesn't carry A failing screenshot, by itself, is a puzzle: which scenario produced it, what state was the UI supposed to be in, was the data stable, did the page finish loading, is there even a baseline to compare against? Someone has to reconstruct all of that by hand, every time — and that reconstruction is where teams actually lose their time, not in running the tests. There's a second cost, too: if every consuming app writes its own answer to "how do we take and compare screenshots," the organization ends up with many slightly different quality systems. One team blocks releases on visual drift. Another only reports it. A third has ignored their flaky snapshots for months. The shared UI producer can't get one clear answer out of any of it. Too many states to check by hand A single component can behave differently across default, hover, focus, and error states, light and dark themes, short and long labels, different viewports and locales — and no team can eyeball every combination on every release. The fix isn't testing every combination either; that's usually impossible. It's choosing the states that actually matter, making them stable, and running them the same way every time. Quality comes from smart coverage, not infinite coverage. The rule > A screenshot is evidence, not governance. Visual regression earns its keep once the system around it can explain what was tested, why it changed, who owns the call, and whether the release should continue. Next: the design that makes that possible — contracts, adapters, and runners.