Glossary
Regression testing is the practice of re-running tests after code changes to verify that existing functionality still works correctly. The word "regression" means moving backward: a regression bug is a feature that previously worked but is now broken due to a new change.
Regression testing happens at every level of the testing pyramid. Unit-level regression tests verify that individual functions still return expected outputs. Integration-level regression tests verify that APIs and services still communicate correctly. E2E regression tests verify that complete user flows still work from start to finish.
E2E regression testing is the strongest regression safety net because it catches failures that span multiple components. A database migration that changes a column name might pass all unit tests but break the registration flow because the API layer was not updated to match. Only an E2E test that exercises the full registration path would catch this.
Regression bugs are among the most expensive to fix because they affect features that users already rely on. When a login flow that worked yesterday breaks today, users notice immediately, support tickets spike, and trust erodes. Stripe's internal data shows that regression bugs discovered in production cost 6 to 10x more to fix than those caught in CI.
The risk of regressions increases with team size and code velocity. A solo developer making 5 commits/day has low regression risk. A team of 20 engineers merging 100 PRs/week has high regression risk because each change can interact with changes from other developers in unexpected ways. Without automated regression testing, the only safety net is manual QA, which cannot keep pace with modern deployment frequency.
Regression testing also provides institutional memory. When an engineer fixes a bug, the corresponding regression test ensures that bug never comes back, even if a future developer modifies the same code path without understanding the original context.
Most teams run their full E2E suite as regression testing on every PR and nightly. The PR run catches regressions before merge. The nightly run catches regressions from merged changes that interact in unexpected ways.
The challenge is scale. A 200-test regression suite that takes 45 minutes is manageable when you merge 10 PRs/day. When you merge 50 PRs/day, you need either parallelization (splitting tests across multiple CI runners) or test selection (only running tests relevant to each change). Tools like Launchable offer predictive test selection, and diff-aware approaches select tests based on code change analysis.
Manual regression testing still happens at many companies, especially for pre-release milestones. A QA team manually walks through a checklist of critical flows before a major release. This is slow (days instead of minutes) but catches UX issues that automated tests might miss.
Zerocheck runs regression tests on every PR with diff-aware selection, so only the tests relevant to each code change are executed. This keeps feedback loops short (3 to 8 minutes) without sacrificing coverage of affected flows. Results are classified as PASS, FLAKE, or INVESTIGATE, so engineers spend time on real regressions, not false alarms.