When a product is small, you re-test everything. When it grows, "test everything" becomes "test nothing well." A regression strategy is how you decide what not to run.
The Core Question
Regression testing answers one thing: did this change break something that used to work? You can't answer it by re-running 2,000 cases by hand every sprint. You answer it by targeting.
Tiering the Suite
I split regression into three tiers:
- Smoke (10–15 cases): the app boots, login works, core flow completes. Runs on every build.
- Critical path (50–80 cases): money flows, auth, data integrity. Runs before every release.
- Full regression: everything. Runs before major releases or after risky refactors.
Change-Impact Mapping
Before a release I ask developers one question: what did you touch? Then I map it:
| Change | Regress |
| Payment service | Checkout, refunds, order history |
| Auth library bump | Login, signup, password reset, sessions |
| Shared UI component | Every screen that uses it |
A shared component change has a huge blast radius — that's where most "surprise" regressions come from.
Automate the Stable, Explore the New
Automation earns its keep on cases that are stable and repetitive — smoke and critical path. New features are still moving; automating them too early means rewriting tests every sprint. I keep new-feature testing exploratory until the design settles.
Track Escaped Defects
The real scorecard for a regression strategy is escaped defects — bugs found in production that a regression run should have caught. Each one is a case to add to a tier. Over time the suite hardens around your actual failure patterns instead of guesses.