What is regression testing?
Regression testing reruns existing tests after a change to confirm that features which used to work still work.
A regression is a bug in something that previously worked. Regression testing is the practice of rerunning a set of existing tests after every code, configuration or dependency change to catch those bugs before release.
Because the suite grows with every feature, regression testing is almost always automated. The hard part is not running it but keeping it trustworthy: tests must be updated as the product changes, and flaky failures must be separated from real ones.
Example
A team refactors how invoices are calculated. Their regression suite reruns the checkout, billing and export tests and catches that CSV exports now show totals without tax.
Best practices
- Automate the journeys that would hurt most if they broke
- Run the suite on every pull request, not only before releases
- Run tests related to the changed code first for faster feedback
- Classify failures as real bugs, test drift or environment issues
- Retire tests for removed features so the suite stays relevant
Frequently asked questions
What is the difference between regression testing and retesting?
Retesting confirms that a specific fixed bug is gone. Regression testing checks that the fix, or any other change, did not break something else.
How often should regression tests run?
Ideally on every pull request, with a full run nightly or before each release.
Ship without fear.
Start testing free in minutes, or let a QAShift engineer deliver your first morning report within 5 days.