What Is Regression Testing? Types, Tools & How to Automate It
You fixed one bug and shipped. Then the checkout page broke. Regression testing is how teams catch those surprise side effects before users do. This guide explains it in plain words, with examples, a step-by-step process and a checklist.
What is regression testing?
A regression is a bug where something that used to work stops working. It usually happens because code is connected in ways that are hard to see. Think of a plumber who fixes a leak in the kitchen, and the next day the bathroom tap stops working. Regression testing is checking every tap in the house after any repair.
Example: a developer changes how coupon discounts are rounded. The coupon tests pass. But the checkout page uses the same rounding function to calculate tax, and now totals are off by one cent. A regression test on checkout catches it before release.
change
Why regression testing matters
Modern teams ship updates every day. Every change is a chance to break something old. Regression testing gives you four big wins:
Catches hidden side effects
Finds bugs in places nobody touched, which are the hardest bugs for developers to predict.
Makes fast releases safe
Teams can deploy often without fear, because every release is checked the same way.
Lets you clean up code
Developers can refactor (rewrite code to be cleaner) knowing the tests will shout if behavior changes.
Protects revenue flows
Sign-up, checkout and payments keep working, so a small change never quietly costs you customers.
Bugs are expensive. A study for the US National Institute of Standards and Technology (NIST) estimated that software bugs cost the US economy about $59.5 billion per year, and that better testing could remove over a third of that cost.Source: NIST / RTI, "The Economic Impacts of Inadequate Infrastructure for Software Testing" (2002)
Types of regression testing
Not every change needs the full suite. Pick the type based on how big and risky the change is.
Corrective
Re-run existing tests as they are when the code changed but the requirements did not.
Selective
Run only the tests linked to the changed parts of the code. Fast and focused.
Partial
Test the changed module plus the modules that directly depend on it.
Progressive
Write new test cases when requirements change, then run them with the old ones.
Retest-all
Run the entire suite. Slow, but the safest choice before a major release.
Visual regression
Compare screenshots before and after a change to catch layout, font and color breaks.
Regression vs smoke vs sanity testing
These three are often mixed up. In simple terms: smoke testing asks "does the app even start?", sanity testing asks "does this one fix work?", and regression testing asks "did we break anything else?"
| Smoke testing | Sanity testing | Regression testing | |
|---|---|---|---|
| Question it answers | Is the build stable enough to test? | Does the specific fix or feature work? | Did the change break anything that worked before? |
| Scope | Wide but shallow | Narrow and focused | Wide and deep |
| When | On every new build | After a small fix | After any change, before every release |
| Time | Minutes | Minutes | Minutes to hours |
| Usually automated? | Yes | Often manual | Yes, ideally fully |
How to do regression testing, step by step
Find what changed
Read the pull request or release notes. List the files, features and APIs that were touched.
Map the impact
Ask "what else uses this code?" Shared functions, components and APIs spread risk to other pages.
Pick and prioritize tests
Run the highest-risk tests first: money flows, login, and anything used by most users.
Run them automatically
Trigger the suite in CI (the system that builds and checks every code change) so nobody has to remember.
Triage failures
For each red test, decide: real bug, expected change, or flaky test. Fix or update accordingly.
Grow the suite
Every bug that reached users gets a new regression test, so the same bug can never return silently.
When should you run regression tests?
A common pattern is to run small, fast checks often and the full suite less often:
Fast checks on the changed areas.
All automated tests on staging.
Everything, plus screenshot checks.
The fix and everything around it.
Bar length shows roughly how much of the suite runs.
Automating regression testing: tools and examples
Regression tests run again and again, so they are the best candidates for automation. Popular options:
| Tool | How it works | Good fit for |
|---|---|---|
| Selenium | Open-source browser automation with support for many programming languages | Large teams with existing Java, Python or C# suites |
| Playwright | Open-source framework from Microsoft; tests Chromium, Firefox and WebKit, with built-in screenshot comparison | Modern web apps and visual regression checks |
| Cypress | JavaScript test runner that runs inside the browser with a live, visual test view | Frontend teams working in JavaScript |
| TestHive | AI agent that tests your site from plain-language goals, with no scripts to maintain | Teams tired of fixing broken scripts after every UI change |
// Visual regression check test('checkout looks right', async ({ page }) => { await page.goto('/checkout'); await expect(page) .toHaveScreenshot(); });
# Plain-language regression goal Goal: Buy 2 items with coupon SAVE10 Then: total = subtotal - 10% + tax And: confirmation page loads Run: on every pull request
Regression testing best practices
- Automate the repeat workIf a test runs more than twice, automate it.
- Prioritize by riskMoney, login and high-traffic pages run first.
- Run on every pull requestCatch regressions minutes after they are written.
- Add a test for every escaped bugStops the same bug coming back.
- Kill flaky tests fastA test that fails randomly teaches people to ignore red.
- Keep test data cleanReset data before each run so results are repeatable.
- Add visual checksScreenshots catch broken layouts that code checks miss.
- Review the suite monthlyDelete tests for removed features; keep it lean.
Frequently asked questions
What is regression testing, in simple words?
It is re-checking that old features still work after you change the code. You run your existing tests again to make sure the new change did not break anything.
What is the difference between retesting and regression testing?
Retesting checks that a specific bug is really fixed. Regression testing checks that fixing it did not break something else. Teams usually do both after a bug fix.
Is regression testing functional or non-functional?
Mostly functional (does the feature behave correctly), but it can also cover non-functional things like performance and visual appearance.
Can regression testing be fully automated?
Most of it can and should be. Keep some manual exploratory testing for usability and new edge cases that no one has written a test for yet.
What is the difference between smoke testing and regression testing?
Smoke testing is a quick check that the build works at all. Regression testing is a deeper check that every existing feature still works after a change.
How often should regression tests run?
Fast, focused tests on every pull request; the full suite nightly and before every release.
Catch regressions before your users do.
TestHive's AI agent re-tests your key user journeys on every change, with no scripts to maintain.
Try TestHive now →