What Is Regression Testing? A Guide for Teams That Ship UI
Last updated: September 24, 2026
Regression testing is re-running tests after a code change to confirm that features which already worked still work. A regression is anything that used to be right and now is not: a broken checkout, a button that shifted 8px, a label that lost its contrast. The goal is to catch those side effects before users do.
What Is Regression Testing?
Wikipedia defines regression testing as "re-running functional and non-functional tests to ensure that previously developed and tested software still performs as expected after a change." The change can be anything: a bug fix, a new feature, a dependency upgrade, a CSS refactor, or a config flag. If something that passed before fails now, that is a regression.
The idea is older than most of the tools that run it. Fred Brooks described the problem in 1975, and the line still explains why every serious team keeps a regression suite:
Program maintenance requires far more system testing per statement written than any other programming. Theoretically, after each fix, one must run the entire batch of test cases previously run against the system to ensure that it has not been damaged in an obscure way. Fred Brooks
Two words in that quote matter for anyone who ships an interface: "non-functional" in the definition, and "obscure" in Brooks. Most regression suites cover function well. The obscure damage is usually visual, and it is usually the part nobody wrote a test for.
Regression Testing vs Retesting vs New Feature Testing
These three get used interchangeably. They answer different questions.
| Regression testing | Retesting | New feature testing | |
|---|---|---|---|
| Question | Did this change break anything that already worked? | Is the bug we fixed actually fixed? | Does the new thing work as specified? |
| Scope | Existing features near, or far from, the change | The one failing case | Only the new feature |
| Trigger | Any change: code, dependency, config, styles | A fix is deployed | A feature is ready for QA |
| Example | After a cart refactor, checkout and order history still work | The login test that failed on validation now passes | The new subscription flow works end to end |
Types of Regression Testing
Regression testing types are mostly about scope: how much of the suite you re-run for a given change. Pick the smallest scope that still covers what the change could plausibly touch.
| Type | What you re-run | Use it when |
|---|---|---|
| Unit regression | Tests for the single function or module that changed | The change is isolated, like a pricing calculation |
| Partial regression | The changed module plus the modules that depend on it | A change touches shared logic, like cart state |
| Selective regression | A pre-chosen subset: critical, high-traffic, or historically fragile flows | Every pull request, when a full run is too slow |
| Complete regression (retest all) | The entire suite | Before a major release, framework upgrade, or redesign |
| Progressive regression | Existing tests plus new tests written for the change, in the same sprint | Features change existing behavior on purpose |
| Visual regression | Screenshots of pages or components, diffed against approved baselines | Any change to styles, layout, fonts, or shared components |
The Four Kinds of Regression (and What Catches Each)
The types above describe how much you re-run. A more useful question for a team that ships UI is what kind of thing broke, because each kind needs a different check. A green functional suite says nothing about the other three.
| Regression | Example | What catches it | What misses it |
|---|---|---|---|
| Functional | Checkout button no longer submits the order | Unit, integration, and end-to-end tests (Playwright, Cypress, Selenium) | Nothing, if the flow has a test |
| Visual | A shared card component now clips its title on mobile | Screenshot diffing against a baseline (Playwright, Percy, Chromatic) | Functional tests: the element still exists and still clicks |
| Accessibility | A brand color update drops body text below 4.5:1 contrast | Automated WCAG checks (axe-core) re-run on every change | Functional tests, and visual diffs if the new color was approved |
| Design system | A hard-coded hex replaces a token, so dark mode breaks later | A token audit of the live page against your design tokens | Visual diffs: the hex renders identically today |
Accessibility is the kind most teams under-cover, and the numbers show it. The WebAIM Million 2026 report found detected WCAG failures on 95.9% of the top one million home pages, up from 94.8% in 2025, and an average of 56.1 errors per page, up 10.1% in a year. Low-contrast text alone appeared on 83.9% of pages. Those are regressions at web scale: the numbers had been improving for six years and then went backwards (WebAIM, 2026).
For more on why a passing suite can still ship a broken page, see Why UIs Pass Every Test and Still Break in Production.
How to Do Regression Testing, Step by Step
A process that works for a team shipping every week:
- Define the regression suite: list the flows that must never break (sign-up, login, checkout, search, core pages) and the tests that cover them. Include visual and accessibility checks for your most-visited pages, not only functional ones.
- Run impact analysis on the change: which modules, components, and pages depend on what changed? A shared button or a global stylesheet has a far larger blast radius than its diff suggests.
- Choose the scope: selective for everyday pull requests, partial when shared code moved, complete before a major release or dependency upgrade.
- Run automated checks in CI: functional tests, screenshot diffs, and automated accessibility rules on every pull request, so a regression blocks the merge instead of reaching production.
- Run a manual pass on what automation cannot judge: real devices, odd viewports, interactive states, and whether the page still matches the design. Log what you find with a screenshot and the element it affects.
- Fix, then retest: re-run the failing case and its neighbours. A fix is itself a change, and it can regress something else.
- Update the suite: add a test for every regression that escaped, and delete tests for features you retired. A suite nobody trusts stops being run.
How Much of the Suite Should You Re-Run?
Running everything on every change is the safest option and, past a certain size, the slowest. The answer at scale is regression test selection: pick the tests most likely to fail for this specific change.
Meta published results from its machine-learning approach, predictive test selection. It learns from historical changes and test outcomes which tests tend to fail for which kind of change. Meta reported it caught more than 99.9% of regressions while running about a third of all tests (Engineering at Meta). Most teams do not need a model to get most of that benefit. Tag tests by the area they cover, run the tags that match the files changed, and run the full suite nightly.
Tip: Selection works for code because tests map to files. It works poorly for styles. A one-line change to a design token or a global stylesheet can touch every page, so treat style changes as a trigger for a wide visual and accessibility pass, not a narrow one.
Automated vs Manual Regression Testing
Automate anything that is repeatable and has a clear pass or fail: flows, API contracts, screenshot diffs, and rule-based accessibility checks. Keep people on the judgments automation cannot make.
What still needs a human, or a check that compares against intent:
- Whether the baseline was ever right: screenshot tools diff against an approved image, not the design. Playwright's own docs say it plainly: "On first execution, Playwright test will generate reference screenshots. Subsequent runs will compare against the reference." Whatever shipped first becomes the truth (Playwright).
- Intentional changes that went too far: a redesign diff gets approved as a whole, and a real regression hides inside it.
- States screenshots skip: hover, focus, error, empty, loading, and long-content cases.
- Rendering differences: fonts, devices, and browsers that differ from the CI environment where baselines were captured.
This is the gap between regression testing and design QA. A regression suite tells you what changed. Design QA tells you whether it matches what was designed. The two are compared in detail in Design QA vs Visual Regression Testing.
Regression Testing Tools by Layer
| Layer | Tools | What they check |
|---|---|---|
| Functional | Playwright, Cypress, Selenium | Flows still work end to end |
| Visual | Playwright screenshots, Percy, Chromatic, Applitools | Pixels still match an approved baseline |
| Accessibility | axe-core, WAVE, OverlayQA scheduled scans | WCAG rules still pass after each change |
| Design fidelity | OverlayQA | The live page still matches the design and its tokens |
| Test management | Zephyr, TestRail | Which regression cases ran, passed, and failed per release |
For a deeper look at the screenshot layer, see Best Visual Regression Testing Tools in 2026.
How to Measure Your Regression Testing
Four numbers tell you whether the suite is earning its runtime:
- Escaped regressions: regressions found in production per release. This is the number that matters most, and it should trend down.
- Where escapes came from: functional, visual, accessibility, or design system. If every escape is visual, adding functional tests will not help.
- Suite run time: if a pull request waits 40 minutes, people start skipping it.
- Flaky rate: tests that fail without a real change. Every flaky test teaches the team to ignore red.
Catch UI Regressions on the Live Page
OverlayQA covers the layers a functional suite leaves open. In the browser, it detects visual, accessibility, and design-token issues on any page, including localhost and staging, and compares the live build against your design. Scheduled scans re-run accessibility, contrast, and design token checks on the pages you watch, keep a baseline of every finding, and email you only when a scan finds something new or fixed. That is regression testing for the parts of the page no test asserts on.
Your test suite checks that the page works. OverlayQA checks that it still looks and reads right: visual, accessibility, and design-token regressions detected on the live page with AI analysis and CSS extraction. Export to Jira, Linear, Notion, Slack, Asana, Trello, ClickUp, GitHub Issues, Basecamp, or monday.com with the selector, computed values, and screenshot attached.
Frequently Asked Questions
What is regression testing in simple terms?
Regression testing means re-checking things that already worked after you change something. If you fix a bug in the cart and re-run the checkout, login, and order history tests to make sure they still pass, that is regression testing. Anything that used to work and now does not is called a regression.
What is the difference between regression testing and retesting?
Retesting confirms that one specific bug is fixed by re-running the test that failed. Regression testing confirms that the fix, or any other change, did not break something else. Retesting is narrow and targeted. Regression testing is broad and looks at everything the change could have affected.
When should you run regression tests?
Run regression tests after any change to code, dependencies, configuration, or styles: on every pull request for a selected subset, on a nightly schedule for the full suite, and before every major release. Style and design token changes deserve a wide visual and accessibility pass, because one line can affect every page.
Can regression testing be automated?
Most of it can. Functional flows, screenshot comparisons, and rule-based accessibility checks all run well in CI. What automation cannot judge is whether the approved baseline was correct to begin with, whether the page still matches the design, and states the tests never render, such as hover, focus, and error states. Those need a manual or design QA pass.
What is visual regression testing?
Visual regression testing captures screenshots of pages or components and compares them to previously approved baseline images, flagging any pixel difference for review. Tools include Playwright screenshot assertions, Percy, Chromatic, and Applitools. It catches layout and styling changes that functional tests pass over, but it cannot flag a problem that was already present in the baseline.