What Is Regression Testing and How Do You Do It?

A customer emails to say checkout is broken. Nobody touched checkout. The team only changed the discount code feature. But the discount change altered a shared pricing function, and now orders with gift cards fail.

That’s a regression: something that used to work and stopped working because of a change somewhere else. Regression testing is how teams catch these problems before customers do. This guide explains what regression testing is, how to decide what to retest, and how to automate it so releases stop breaking old features.

What regression testing means

Regression testing is re-running existing tests after a change to confirm that the change didn’t break anything that already worked. The change could be a new feature, a bug fix, a refactor, a library upgrade, a configuration change or new infrastructure.

It’s different from the testing you do on the change itself:

• Testing the new feature asks: “Does the new thing work?”
• Confirmation testing (also called retesting) asks: “Is the bug we fixed actually fixed?”
• Regression testing asks: “Did anything else break along the way?”

Regressions happen because software is connected. Shared functions, databases, APIs, styles and third-party libraries mean a change in one place can ripple out. The bigger and older the codebase, the harder it is for any one person to predict those ripples.

Why releases keep breaking old features

If your team keeps shipping bugs into features nobody touched, the usual causes are:

• No automated tests for existing behavior. Each release depends on someone remembering to click through everything.
• Tests that exist but don’t run. They live in the repository but aren’t part of the build pipeline.
• Manual regression that’s too slow. A full manual pass takes days, so it gets cut short when deadlines hit.
• Flaky tests. Tests that sometimes fail for no real reason train the team to ignore failures.
• Dependency updates without testing. A library upgrade changes behavior in ways the release notes didn’t mention.
• Faster code changes. AI coding assistants and large refactors can touch many files at once, which raises the chance of side effects.

Regression testing fixes these by making “check the old stuff still works” automatic and routine.

Types of regression testing

Most teams combine these: a smoke test and selective regression on every change, and full regression before release.

Key takeaway: Every bug you fix should leave behind a test. Over time, that habit turns your regression suite into a record of everything that has ever broken, and stops it breaking again.

How to choose what to retest

You can’t test everything all the time, so scope selection matters. Use these questions to decide what goes into each run:

1. What changed? Start with tests for the modified code and anything that calls it.
2. What depends on it? Shared libraries, database tables, APIs and design components affect many features.
3. What would hurt most if it broke? Payments, sign-in, sign-up, data saving and anything legally or financially sensitive belong in every run.
4. What has broken before? Areas with a history of bugs deserve permanent coverage.
5. What do customers use most? Analytics show which flows matter to real users.

Some tools automate part of this. Microsoft’s Test Impact Analysis in Azure Pipelines, for example, selects the tests affected by a commit, plus previously failing and newly added tests, and falls back to running everything when it can’t tell what changed. Test frameworks also help you organize tests into groups. In pytest, for instance, you can mark tests and run subsets, such as pytest -m "not slow" for a quick run.

Automating regression tests

Manual regression doesn’t scale. Each release adds features to check, while the time available stays the same. Automation is what makes regular regression testing realistic.

Build the suite in layers. Most regression coverage should come from fast unit and API tests, with a smaller number of end-to-end tests for critical user journeys. Our guide to unit vs integration vs end-to-end testing explains how to balance them.

Run it in your pipeline. Connect tests to your CI/CD pipeline so they run on every pull request. On GitHub, branch protection can require status checks to pass before changes are merged, which stops a failing regression suite from being ignored.

Split fast and slow runs.

Add visual checks for front ends. Screenshot comparison tools catch layout changes unit tests miss. Playwright’s visual comparisons, for example, store a reference screenshot and compare later runs against it. Its documentation warns that rendering varies by operating system, browser and hardware, so generate baselines in the same environment where tests run.

Keep a manual layer. Automation checks what it’s told to check. Short exploratory sessions on risky changes still find surprises. See manual vs automated testing for where each fits.

Keeping the regression suite healthy

A regression suite is code, and it needs maintenance.

• Fix or quarantine flaky tests quickly. A test that fails randomly destroys trust in every other result. Track flaky tests, move them out of the blocking run and fix the cause.
• Delete tests for removed features. Old tests slow every run and confuse new team members.
• Watch run time. If the pull request run creeps past 10 to 15 minutes, developers start working around it. Parallelize or move slower tests to later stages.
• Use stable test data. Create test data in each test or reset it between runs, so tests don’t depend on each other.
• Review coverage of critical flows. Coverage percentages are a rough guide. What matters is that your most important user journeys are tested.

Where to start: a 6-step plan

1. List your top 10 user journeys. Sign-up, login, search, checkout, key forms, reports. Ask support which ones generate the most complaints.
2. Automate a smoke test for each. Even a simple check that each journey completes catches a lot.
3. Run tests on every pull request. Make passing tests a requirement for merging. Our guide to building a CI/CD pipeline shows how.
4. Adopt the “bug, then test” rule. Every bug fix includes a test that would have caught it. Test-driven development makes this natural.
5. Schedule a full run before releases. Include browsers, devices and integrations you support.
6. Review monthly. Remove dead tests, fix flaky ones and add coverage where bugs escaped to production.

Pair this with a pre-launch QA checklist for release day and move checks earlier with shift-left testing.

Conclusion

Regression testing is the safety net that lets teams change software without breaking what already works. Choose what to retest based on what changed, what depends on it and what matters most to customers. Automate the bulk of it in layers, run a fast subset on every change and the full suite before release, and add a test for every bug you fix. Keep the suite fast and trustworthy, and releases stop being a gamble.

Sources

• Microsoft Learn: Test Impact Analysis — selecting impacted tests and fallback to running all tests
• pytest documentation: Working with custom markers — marking and selecting test subsets
• GitHub Docs: About protected branches — requiring status checks before merging
• Playwright documentation: Visual comparisons — screenshot-based regression checks and rendering caveats