● Last verified Jul 9, 2026
For a long stretch, our regression cycle ran about two months. Two months between “code complete” and “confident enough to ship” — running the whole suite, every release, because that's what you do. Run everything, miss nothing.
Except “run everything” is how you end up running nothing useful fast enough to matter. The cycle was so long that feedback arrived after the decisions it should have informed. We got it down to about a month — roughly half. The lever wasn't more machines or more people. It was deciding, on purpose, what not to run.
The bottleneck isn't coverage. It's undifferentiated coverage.
A regression suite that runs everything treats every test as equally important on every release. It isn't, and you already know it isn't. A change to one service does not put the entire application at risk — but a run-everything suite spends the same two months proving the untouched 90% still works as it does pressure-testing the 10% that actually changed.
That's not safety. It's the appearance of safety, bought with the one resource a release can't spare: time. The longer the cycle, the later the feedback, and the more the rest of the org learns to route around QA instead of through it.
The method: audit first, then triage, then formalize it
The instinct to “just go risk-based” skips the part that actually made it work. Before any test got reprioritized, I answered a much duller question first: what were we even running, and why?
- Audit the suite as it actually existed. What ran, who ran it, when, where, and why — not what the test plan claimed, what actually happened release after release. Then map the inputs and outputs of that data and every stakeholder with a stake in it: who consumed the results, who owned the systems under test, who'd feel it if a tier got cut.
- Heat-map the coverage. Plotted the current tests against the areas of the application they actually exercised. That's what turned “we probably cover the important stuff” into a picture — showing exactly where coverage was thick, where it was thin, and where it didn't exist at all.
- Get business to define “critical,” not QA alone. Partnered with business stakeholders to build a rubric for what functionality had to be in the regression suite. A rubric survives someone leaving the team; a gut feeling doesn't.
- Model what the vendor platform already recommended. Rather than invent a coverage strategy from nothing, I looked at the testing platform's own guidance for regression coverage and adopted what actually fit our shop instead of reinventing it from scratch.
- Formalize it as risk-based testing, ISTQB-style. Scored product risk the way the standard defines it — likelihood a component fails, weighted by the impact if it does — so tiering the suite stopped being a judgment call and became a documented, repeatable method.
That's five inputs, not one clever idea: an honest audit, a coverage map, a business-built rubric, vendor guidance, and a formal risk model layered on top. Applied together, that's what took the cycle from two months to one.
The question stops being “did we run everything?” and becomes “did we run what this change can actually break?” A tier assignment that came from a documented rubric and a risk score survives an audit — and survives you leaving the team — in a way that a senior tester's gut feeling never does.
Run everything vs. run what matters
| Run everything, every release | Risk-based regression | |
|---|---|---|
| Cycle time | ~2 months | ~1 month |
| Feedback | late, all at once | fast, where it matters |
| How “critical” gets decided | tribal knowledge, whoever's loudest | a rubric, built with business, scored like risk |
| Maintenance pressure | every test must always be green | invest in the tests that carry risk |
| Real failure mode | so slow teams route around QA | a wrong risk model skips the wrong test |
| Safety net | “we ran it all” (an illusion of done) | tiered runs + scheduled full sweep + RCA loop |
The left column feels safer. The right column is safer, because feedback that arrives in time can actually change the release.
One real workflow per email
If this was useful, I send one practical QA writeup like it when it's worth your time — a pattern, a gotcha, or a piece of the field kit I actually use. No roundups, no filler.
Where this breaks
Risk-based regression is only as good as your model of risk. Guess wrong about what a change touches and you skip the exact test that would have caught it — and now you've shipped a gap with confidence, which is worse than shipping it scared.
So it isn't “run less” — it's “run less, on purpose, with a net.” Three things keep the model honest:
- A cheap full sweep on a cadence (nightly or weekly), so “not this release” never quietly becomes “never.”
- An escaped-defect feedback loop. Every bug that reaches production is a vote that the risk model missed something. Feed root-cause findings back into the rubric and the risk scoring — not just into a retro doc nobody rereads.
- Visible coverage of what you skipped, so the release decision is made with eyes open, not assumed.
Skip those three and “risk-based” is just “we stopped testing and hoped.” The rubric and the risk score only stay honest if something is feeding them back — a defect that escapes, a full sweep that catches drift, a coverage view nobody has to ask for.
My rule of thumb
Don't run every test every time. Run what the change can actually break, keep a cheap net under the rest, and let escaped defects correct your aim. A regression cycle exists to produce a confident release decision — not to prove, slowly, that nothing moved.
Better tests. Better releases. Less theater.
// take this with you
Risk-Based Regression Triage Sheet — a one-pager: the five inputs that build the model (audit, coverage heat map, business rubric, vendor guidance, ISTQB-style risk scoring), and the two safety nets that keep it honest. The thing you'd hand a lead who's drowning in a run-everything cycle.
Open it in the Field Kit →