Field Kit · reference card
Risk-Based Regression Triage Sheet
Five inputs build the model. Two safety nets keep it honest. Print this before your next suite redesign.
The five inputs
Don't start with "what's the risk?" Start with what's actually true about the suite you have.
What ran, who ran it, when, where, and why — not what the test plan claimed, what actually happened release after release. 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.
Plot the current tests against the areas of the application they actually exercise. Turns "we probably cover the important stuff" into a picture — where coverage is thick, where it's thin, where it doesn't exist.
Partner with business stakeholders to build a rubric for what functionality has to be in the regression suite. A rubric survives someone leaving the team; a gut feeling doesn't.
Don't invent a coverage strategy from nothing. Check the testing platform's own guidance for regression coverage and adopt what actually fits your shop.
Score product risk the way the standard defines it — likelihood a component fails, weighted by the impact if it does. Tiering the suite stops being a judgment call and becomes a documented, repeatable method.
The two safety nets
Risk-based only stays honest if something keeps checking it. Skip these and "risk-based" is just "we stopped testing and hoped."
Nightly or weekly, run the whole suite regardless of tier. That's what keeps "not this release" from quietly becoming "never."
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.