Enough to give you confidence that the change has not broken important existing behaviour. Not every test anybody has written since the dawn of the programme.
Regression packs grow like loft clutter. Nobody wants to throw anything away because it might be useful one day. A few years later the team is running 4,000 checks to release a change to an email template.
A good regression review often saves more time than another month of automating the pile. The useful job is pruning the pack once nobody can explain why half of it still exists.
Regression should follow change and risk
Start with what changed directly. Then look at what depends on it, what shares data or components with it and which critical journeys could be affected indirectly. Add a sensible baseline around the product’s most important functions.
That is far more useful than blindly running everything because the spreadsheet says ‘full regression’.
Automation helps when the checks are stable, meaningful and cheap to run. It becomes less impressive when a large suite takes hours, fails randomly, gets rerun until green and nobody can explain what business risk half the scripts cover. A green pipeline is no substitute for understanding why automated tests can pass while software is broken.
Delete things
A mature regression pack should lose tests as well as gain them. Remove duplicates. Retire checks for features that no longer exist. Stop manually repeating low-value scenarios that have never found anything and are already well covered elsewhere.
The purpose is not maximum activity. The purpose is useful confidence at a sensible cost.
Worked example: a change to checkout payments
Suppose a developer changes the payment retry handler. Testing every screen in the product would be convenient for the regression dashboard and miserable for everyone else.
- Always include: Successful payment, declined payment, duplicate-submit protection, retry after timeout and the correct order status after each result. Confirm that an account cannot be charged twice.
- Follow the change: Check refund and reconciliation records if they use the same transaction logic, and test the integration between checkout and the payment provider.
- Keep a small baseline: Login, the main purchase journey and any known fragile shared components; do not automatically rerun all old account-profile and marketing-page tests.
- Only broaden if evidence warrants it: If the retry change also modifies shared session management or database transactions, widen the regression around those dependencies.
Record the reason for inclusion and exclusion. If the last two production incidents involved duplicate charges and lost order confirmation, prioritise those failure modes. A short, defensible regression set is better than a massive one whose only proof of quality is that somebody found time to click everything.
Use production history to tune the pack
A regression suite should learn. If the last year of incidents shows repeated failures around account recovery, data migration or external callbacks, those areas deserve durable coverage. If a huge block of tests has never found a meaningful issue and protects something with tiny consequence, question why it still consumes time every release.
Also distinguish checks from investigation. Automation is excellent at telling you that something known changed. Exploratory testing is better at asking what nobody thought to script. A sensible regression approach usually contains both rather than treating manual work as a temporary embarrassment waiting to be automated.
The target is not ‘full regression’. The target is enough relevant regression to protect what changed and what matters, with the rest of the time available for testing the new risk you have just introduced.
If your regression takes days and everybody is terrified to remove anything, get onto us. We can review the pack, map it to actual risk and change, identify dead weight and tell you what we would keep, automate, reduce or stop doing altogether.