What is the difference between regression testing and retesting?

Retesting verifies that a specific bug you just fixed is actually gone by re-running the exact reproduction steps. Regression testing is broader: it re-runs the surrounding suite to confirm the fix (or any other change) didn't break something else. You almost always do both — retest the fix, then regression-test the area around it.

How often should you run regression tests?

Run a fast regression subset on every pull request or merge, and a full regression pass before each release. If a change touches shared code — authentication, payments, a core data model — expand the subset to cover everything downstream of it rather than trusting a fixed list.

Can regression testing be automated?

Yes, and it is the single best QA activity to automate because it is repetitive, runs on every change, and follows fixed steps. Manual regression testing does not scale past a handful of releases. Automate the stable, high-value paths first and keep exploratory testing manual.

What Is Regression Testing? Types and When to Run It

Regression testing is re-running your existing tests after a change to confirm that features which already worked still work. The word "regression" means a feature has slipped backward from working to broken, and this kind of testing exists to catch that slip before your users do. The trigger is always change — a bug fix, a new feature, a library upgrade, or a config edit — because any change can break something in code you never touched.

What does regression testing actually do?

It answers one question: did this change break anything that used to work? A regression suite is the set of checks you keep re-running to answer that question over and over, release after release. Unlike a one-off test written to verify a new feature, a regression test is meant to live forever and run on every future change.

Three concrete things make regression testing worth the effort:

It catches side effects. Most breakages aren't in the code you edited — they're in code that quietly depended on it. A change to a shared date formatter can break invoices, exports, and email templates at once. Only a broad re-run finds that.
It protects fixed bugs. A bug that was fixed but never covered by a test will eventually come back when someone refactors nearby. A regression test freezes the fix in place.
It builds release confidence. The point of a green regression run is not zero risk — it's knowing exactly which behaviors you have verified, so you can ship without guessing.

What are the types of regression testing?

"Regression testing" is an umbrella term. In practice teams run one of a few scopes depending on how risky the change is:

Full regression. Re-run the entire suite. Reserve it for releases, major dependency upgrades, or changes to shared infrastructure where the blast radius is hard to predict.
Partial (selective) regression. Re-run only the tests related to the changed area plus its known dependents. This is the everyday mode for pull requests, and choosing the subset well is the whole skill.
Smoke regression. A thin slice of critical-path tests — can users log in, load the dashboard, and complete the core action — run first and fast to reject obviously broken builds before deeper testing.
Unit-level regression. The fast checks around individual functions that run on every save and every commit. They catch the narrowest breakages earliest and cheapest.

When should you run regression tests?

Tie the run to the change, not to the calendar. A practical cadence:

On every pull request: run a selective regression subset plus the smoke tests, so no change merges without proof it didn't break the critical paths.
Before every release: run the full suite, because a release bundles many changes whose combined effects no single PR run has verified together.
After a dependency or config change: treat upgrades and infrastructure edits as high-risk and widen the scope — these break things in places code review rarely predicts.
After every bug fix: retest the specific fix, then run the regression tests around it to confirm the fix didn't introduce a new problem nearby.

How do you choose which tests to re-run?

You can't re-run everything on every commit forever — suites get slow and people start skipping them. The way to keep regression testing useful is to select by change impact:

Map the change to its dependents. Ask what code, data, and UI paths consume the thing you edited, and pull their tests into the run — not just the tests for the file you touched.
Weight by risk and traffic. Always include the paths that most users hit and the ones that cost the most when they break, like sign-in and checkout, even if the change looks unrelated.
Grow the suite from real bugs. Every time a bug escapes to production, add a test for it. Over time your regression suite becomes a memory of every way the product has broken before. See how to turn a bug into a regression test that sticks.

Why regression suites break — and self-healing tests

The hidden tax of automated regression testing is maintenance. When the UI changes, tests fail not because the feature broke but because a selector moved or a button was renamed. Teams that let this rot end up ignoring red builds, which defeats the purpose. Two habits keep a suite trustworthy:

Fix flakiness at the root. A test that fails intermittently teaches people to hit "re-run" instead of investigate, and a real regression eventually hides inside the noise.
Reduce brittle selectors. Tests tied to fragile CSS paths or auto-generated IDs break on cosmetic UI edits that changed no behavior at all.

This is where self-healing end-to-end tests help: when a selector moves, the test repairs its own locator instead of failing the whole run, so a renamed button doesn't turn into a false regression. It removes the maintenance drag that makes teams abandon regression testing in the first place — and when a change is a genuine break rather than a moved element, the failure that surfaces is a real one worth acting on. When those real failures do appear, capturing full evidence — steps, environment, console, and network — with right-click bug reports keeps the fix loop short.

The bottom line

Regression testing is the discipline of proving that change didn't cost you working features. Run a fast subset on every pull request, a full pass before every release, and grow the suite from every real bug you find. Automate the stable paths, keep the suite honest by killing flakiness, and regression testing shifts from a release-day scramble to a quiet, continuous safety net.