Regression Test Strategy.

Regression testing re-checks that things which used to work still work after a change. New code, bug fixes, config changes, and dependency upgrades can all break something that passed last release — regression is how you catch that before users do.

A regression strategy is the plan for doing this sustainably. Rather than "re-test everything" (impossible at scale) or "re-test whatever we remember" (unreliable), it sets a deliberate, repeatable answer to what gets re-tested, how often, and by what means.

A regression pack should cover the things that hurt most if they silently break: the core user journeys, the critical business flows (login, checkout, payments), and the areas around recent changes. Add anything with a history of breaking — past defects are the best predictor of future ones.

Be deliberate about what's out, too. Stable, low-risk areas that haven't changed in months don't need re-running every release; a periodic check is enough. The aim is a pack that protects what matters, not one that grows forever because nothing is ever removed.

Prioritise by risk and by change. Risk tells you which areas are most painful if they break; change tells you which areas are most likely to have broken this release. The intersection — high-risk areas near recent changes — runs first and always.

From there, band the rest: high-priority cases every release, medium on a rotation or when their area is touched, low-risk stable areas on a periodic full pass. This keeps the every-release run small enough to actually complete while nothing important goes unchecked for long.

These three get used interchangeably but solve different problems. A quick comparison keeps them straight — and keeps you from running a two-hour regression suite when a five-minute smoke check was the right call.

Regression is the strongest candidate for automation in all of testing, because the same checks run release after release — exactly where automation pays back. Stable, repetitive, high-value regression cases should be automated and wired into CI so they run on every change with no human cost per run.

Manual regression still has a place: brand-new areas not yet stable enough to automate, exploratory passes around risky changes, and anything where human judgement on look-and-feel matters. The healthy split is automated for the stable core, manual for the new and the nuanced — not all-or-nothing either way.

When the full suite won't fit the window, select by risk rather than running a random subset. Score each area by impact and likelihood of breakage, then run the high-risk and recently-changed areas every release and rotate the rest. A defect found in production is a signal to re-score that area, not to silently re-add everything.

This is risk-based testing applied to regression specifically, and it's what keeps a growing suite from strangling the release cadence. The detail of scoring impact and likelihood lives in the risk-based testing guide, linked below.

A regression pack rots if nobody tends it. Cases drift out of date, duplicate each other, or test behaviour that no longer exists — and an unmaintained pack costs time while quietly covering less. Review it regularly: remove obsolete cases, merge duplicates, and add coverage for new features and recent escapes.

Treat the pack as a living asset with an owner, not an archive. Every time a defect escapes to production, the fix should include adding or strengthening the regression case that would have caught it — that's how the pack gets smarter instead of just bigger.

Flaky regression tests — ones that pass and fail without any code change — are corrosive, because they train people to ignore red. Once "it's probably just flaky" becomes the default reaction to a failure, the suite has stopped doing its job even when it's catching real bugs.

Treat flakiness as a defect in the test. Set a flake budget, quarantine flaky tests out of the gating run so they stop blocking releases, and fix or delete them within a set time rather than leaving them to erode trust. A smaller suite people believe beats a larger one they've learned to wave through.