Regression Testing
Regression testing re-runs existing test cases after a code change to confirm that new code hasn't broken previously working functionality. It's not about testing what's new — it's about proving that everything that already worked still works, which is why it's the first thing automation typically targets in a CI/CD pipeline.
The trigger for regression testing isn't "we finished a feature" — it's any change: a bug fix, a dependency upgrade, a refactor, even a config change. The risk regression testing manages is that fixing or adding one thing silently breaks another, often in a part of the app nobody thought to check manually.
Full regression suites tend to get large and slow, which is exactly why they're the most common target for test automation — a suite that takes a human two days to run manually can run in minutes as an automated regression pack in a CI/CD pipeline, on every pull request.
Teams manage regression suite size with risk-based testing: not every test needs to run on every change. High-risk, high-traffic paths (checkout, login, payment) run every time; lower-risk edge cases might run nightly or weekly instead. The alternative — letting the suite grow unchecked until it's too slow to run before every release — is how regression testing quietly stops happening at all.
Example
A regression suite entry after fixing a null-pointer bug in checkout:
Re-run: add-to-cart -> apply-coupon -> checkout -> confirm-order
Why: the fix touched the cart total calculation, which the entire checkout flow depends on.Not a new test — an existing one, re-run because the code underneath it changed.
