Blog Post
Design QA vs Visual Regression Testing: What Each One Catches
Last updated: August 4, 2026
Visual regression testing compares your UI against a previously approved screenshot of itself. Design QA compares your UI against the design it was supposed to be built from. That single difference in reference point decides which bugs each one can find. Visual regression testing catches changes. Design QA catches gaps that were there from the first commit.
| Design QA | Visual Regression Testing | |
|---|---|---|
| Compared against | The design file or spec | A previously approved screenshot |
| Core question | Does this match what was designed? | Did this change since last time? |
| Catches | Padding that was never right, wrong token, drifted type scale | Unintended diffs introduced by a new commit |
| Misses | Regressions in areas nobody reviews | Any error already present in the baseline |
| Runs | On a real page, during review | In CI, on every pull request |
| Typical tools | OverlayQA, Applitools Eyes Figma plugin | Percy, Chromatic, Applitools Eyes |
What Visual Regression Testing Actually Compares
Visual regression testing captures a screenshot of your interface, stores it as a baseline, and diffs every future run against that stored image. Chromatic captures snapshots of Storybook stories and compares them to the most recent accepted snapshot found by walking back through the branch's git history. Percy is a CI-first visual testing platform built around approving or rejecting diffs per build. Applitools Eyes is a Visual AI engine that compares renders across browsers and viewports. All three are good at the job they describe: if a developer refactors a shared component and shifts padding on four pages nobody thought to open, a visual regression suite catches it on the pull request.
The Baseline Problem
Chromatic's own documentation defines a baseline as "the last known 'good' state of the story in a given mode," and states that "baselines only update when changes are accepted by you or your team." The baseline is whatever a human approved. It is not the design. Nothing in the pipeline ever opens the Figma file. If the button was 12px from the edge when the design said 16px, and someone approved that first snapshot, the visual regression suite will defend 12px forever. That is not a bug in the tool. The tool is reporting change, and there was no change. This is why teams with green visual regression suites still ship interfaces designers do not recognise.
What Design QA Compares
Design QA changes the reference point. Instead of asking whether the page changed, it asks whether the page matches the design it was built from: spacing, typography, colour, tokens, and component structure. That reframing catches bugs visual regression testing structurally cannot see, because they were never a change. Never-correct spacing shipped at 12px when the design said 16px. Hard-coded values written as a hex literal instead of a token, rendering identically today but failing to follow a theme change. Silent type-scale drift where a heading is 22px instead of the 24px in the scale. Approved-away drift, where a sequence of individually approved diffs collectively moves the UI somewhere nobody chose.
Where the Two Genuinely Overlap
It would be convenient to claim visual regression tools cannot compare against a design, but that is not true. Applitools ships an Eyes plugin for Figma that lets designers export frames into Eyes as visual baselines, so Visual AI can compare a design against the implemented UI, and it supports design-to-design comparison between two versions of the same file. The honest framing is that design QA and visual regression testing are two different comparisons, one vendor has built both, and most teams have only bought one. If your stack is Percy or Chromatic, your pipeline compares your UI to its own history and nothing in it consults the design.
Which One Catches Your Bug
Sort the bug by when it entered the codebase. If it worked last week and looks wrong now, that is a regression, and a visual regression suite in CI is the right tool. If it has looked like this since it shipped, no diff will ever fire, and it needs a comparison against the design. If nobody can agree whether it is wrong, that is a spec problem, not a tooling problem. Most teams discover heavy coverage of the first category and none of the second, because CI is where engineering effort naturally accumulates.
When You Need Both
These are complements, not alternatives. Visual regression testing protects work that is already correct from drifting. Design QA establishes that it was correct to begin with. Running only the first means guarding a baseline you never verified. For a team that has neither: run design QA once against the design file, fix what it surfaces, and only then set your visual regression baselines. Approving baselines before that check bakes today's drift into every future comparison.
How to Run Design QA Without a Manual Diff
Design QA is usually skipped because doing it by hand is slow: someone opens the design in one window, the live page in another, and eyeballs spacing. OverlayQA detects these gaps on the live page itself, overlaying your design against the running build in the browser, inspecting computed CSS on real elements, and flagging accessibility and design-token issues in the same pass. Findings export to Jira, Linear, Notion, Slack, Asana, or Trello with the selector, computed values, screenshot, and page context attached.
Ready to check whether your baseline was ever right? Try OverlayQA free and detect spacing, token, and accessibility gaps against your real build.
Frequently Asked Questions
What is the difference between design QA and visual regression testing?
The difference is the reference point. Visual regression testing compares your interface against a previously approved screenshot of itself, so it reports what changed since the last accepted build. Design QA compares your interface against the design it was built from, so it reports where the implementation diverges from the spec. One measures stability, the other measures fidelity.
Can visual regression testing catch a bug that was always there?
No. A visual regression suite only fires when a snapshot differs from its baseline, and the baseline is whatever a human previously approved. Chromatic's documentation defines a baseline as the last known good state of a story and notes that baselines only update when changes are accepted. If a component shipped at 12px when the design said 16px and that first snapshot was approved, no future diff will ever flag it, because nothing changed.
Do Percy, Chromatic, or Applitools compare against Figma designs?
Percy and Chromatic compare against stored baseline screenshots, not design files. Applitools is the exception: its Eyes plugin for Figma lets designers export frames into Eyes as visual baselines so Visual AI can compare a design against the implemented UI, and it also supports design-to-design comparison. If your stack is Percy or Chromatic alone, nothing in your pipeline consults the design file.
Do you need both design QA and visual regression testing?
They are complements. Visual regression testing protects work that is already correct from drifting, and design QA establishes that it was correct to begin with. Running only visual regression testing means guarding a baseline nobody verified. A sensible order is to run design QA against the design file first, fix what it surfaces, and only then set your regression baselines.