What regression testing actually means
A regression is when working software stops working because of a change. A developer fixes a bug in the checkout flow and accidentally breaks the login redirect. A designer updates the navigation component and breaks the mobile menu. A backend change updates an API response format and breaks a form that was consuming it.
Regression testing is the systematic process of checking that these kinds of breakages have not occurred after a change. It is not about testing new features — it is about protecting existing features from unintended side effects.
- Any code change can introduce a regression — features, bug fixes, dependency updates, refactors
- Regressions are most expensive when caught in production by real users
- Manual regression testing before each release is the most common form — and the most costly
- Automated regression suites catch regressions earlier and more consistently
Types of regression testing
Full regression testing re-runs the entire test suite after any change. It provides maximum coverage but is slow and resource-intensive — practical for major releases but not for every pull request.
Selective (or partial) regression testing re-runs only the tests related to the changed code. Faster, but requires tools or judgment to determine which tests are relevant. Risk of missing cross-cutting regressions.
Progressive regression testing adds new tests as features are added, maintaining a growing suite that reflects the current application. This is the standard approach for teams using CI/CD — the suite grows with the product.
Why automated E2E tests are the most valuable regression layer
Unit and integration tests catch regressions at the code level. End-to-end tests catch regressions at the user experience level. Both matter, but E2E tests are uniquely able to detect the class of regression that most directly impacts your users — broken flows, missing navigation, failed form submissions.
Assert's Markdown-based test scenarios serve as living documentation of expected user behaviour. Running those scenarios on every pull request turns regression testing from a pre-release ritual into a continuous, automated baseline.
FAQ
What is the difference between regression testing and retesting?
Retesting verifies that a specific bug that was reported and fixed is no longer present. Regression testing verifies that fixing that bug (or making any other change) has not broken something else. Retesting is targeted; regression testing is broad.
How often should you run regression tests?
Ideally on every pull request. Automated E2E regression tests integrated into CI run automatically on every code change, giving the fastest possible feedback. Teams that cannot run the full suite per PR often run a smoke test subset on PRs and the full suite nightly.
What is a regression test suite?
A regression test suite is the collection of automated tests that cover existing functionality. It grows over time as features are added and as bugs are fixed (the fix is accompanied by a test that would have caught the bug). A well-maintained regression suite is the main defence against shipping broken software.
Put the workflow in your repo, not in a chat transcript
Assert is strongest when scenarios become durable project assets: readable Markdown in the repo, generated execution underneath, and result inspection in the dashboard.