Regression testing without wasting two days

The full manual regression — re-run every test case in the suite before every release — feels responsible and is mostly waste. It burns two days, exhausts the tester, and still misses the bug, because by hour six you're click-click-clicking on autopilot through cases for code nobody has touched in a year. Regression testing isn't "test everything again." It's "make sure the change didn't break something that already worked" — and that's a much smaller, smarter job. Here's how I scope it.

The question regression actually answers

Regression has one job: did this change break something that used to work? That framing immediately tells you where to look — not "everywhere," but "wherever this change could reach." A change to the checkout total can't break the help page. Re-testing the help page isn't thoroughness; it's theatre that costs you the time you needed for checkout.

Start from the change and follow the blast radius

For each release, I map outward from the diff:

1. The change itself — test the new/modified behaviour directly and hard. (That's not regression, but it's where you start.)
2. Direct dependents — what calls this code, what it calls, what reads the data it writes. A change to how prices are calculated reaches the cart, the order summary, receipts, and reporting.
3. Shared components — if the change touched something reused (a shared form component, an auth helper, a date utility), every consumer is in scope. Shared code is where "a tiny change" quietly breaks five features.
4. The core paths, always — login, checkout, the one or two workflows that must never break, get a quick pass regardless, because their cost-of-failure is so high that even a small risk justifies the few minutes.

Everything outside that blast radius is not re-tested this release, on purpose. Going in this order means the stuff you skip is the stuff least able to be affected — the same risk-based logic applied to regression specifically.

Keep a real regression set, not the whole suite

The mistake is treating "the regression suite" as "every test case ever written." Maintain a deliberately small core set — the critical paths and the historically fragile areas — that runs every release no matter what. Everything else is selected per-release based on the change. A 30-case core set you actually run beats a 400-case suite you skim.

Automate the boring repeats, keep judgement manual

The cases that genuinely should run identically every single release — core path smoke checks, calculation-heavy flows — are exactly what automation is for. Hand those to the machine so your manual time goes to the change and its blast radius, where a human's judgement actually finds things. Manually re-running stable, unchanged paths by hand is the specific activity to eliminate. This pairs with writing test cases that are quick to execute and choosing them well with test design techniques.

Write down the scope

Same discipline as risk-based testing: note what regression covered and what it deliberately didn't, and attach it to the sign-off. "Regression: checkout, cart, order summary (touched by pricing change) + core-path smoke. Not re-tested: admin, reporting, help (unaffected)." Now the scope is a visible decision, not a silent gamble.

Where this fits

This is everyday manual-QA process. It's the same risk-based thinking as testing when the deadline is cut, and the scope note lands on the release sign-off. The test plan templates have a place to record the regression scope per release.

Scoping a regression pass

• Test the change itself directly and hard, first
• Map the blast radius: direct dependents, then shared components and their consumers
• Always smoke the core paths (login, checkout, key workflows) regardless of the change
• Maintain a small fixed core regression set — not the entire historical suite
• Automate the truly-identical repeats; spend manual time on the change and its reach
• Write down what regression covered and what it skipped, on the sign-off