In plain English.

For any real product, there is an infinite cloud of possible tests. You do not have forever. You run a finite number. Measured as a percentage of what you could test, your coverage is always zero.

Risk-based testing is how you select which tests to run — and which to cut first when the schedule compresses. This talk answers four questions:

• How do you pick the right tests out of an infinite cloud?
• How do you know when you've tested enough to ship?
• When the schedule slips, which tests should you drop first?
• How do you prove to leadership the trade-off was defensible?

Written for test managers and leadership under constrained schedules. Accessible to any business or technical leader who signs off on a release.

The method in one slide.

Quality risk is the possibility that the product fails to deliver one or more of its key quality attributes.

Risk-based testing:

• Uses an analysis of quality risks to prioritize tests.
• Uses that analysis to allocate effort per risk item.
• Involves business and technical stakeholders so what gets tested lines up with what quality means to the people who live with the product.
• Also manages project risks — events that endanger the project itself — alongside the quality risks.

Find the scary stuff first.

Running tests in risk order finds defects in severity order.

The first bug you find is the bug that matters most. Every fix window you open gets used on the highest-impact defect in the system.

Minimize residual risk at release.

Allocating effort by risk concentrates testing where the stakes are highest.

The residual quality risk at the moment of release is lower than any other allocation you could have chosen with the same test budget.

Know the residual risk during execution.

Measuring by risk tells you where you stand in real time.

You can answer "is this ready?" with evidence instead of opinion. Release when the risk of delay balances the risk of dissatisfaction.

Cut in reverse risk order.

When the schedule compresses, drop tests you worry about least — not tests you happen to have left on the pile.

The same time back, at the lowest possible increase in residual risk.

No. Decreased long-run effort.

Risk-based testing drives more efficient testing overall.

After the initial quality risk analysis, only periodic updates and traceability maintenance are required. Every subsequent release rides on the same analysis — refined, not rebuilt.

Six activities.

1. Train the stakeholders.
2. Hold the quality risk analysis session.
3. Analyze and refine the results.
4. Align testing with the risks.
5. Guide the project by risk.
6. Assess the benefits.

Published in Better Software. Followed by two additional pilots at the same client.

One day. Worked exercise.

Not lecture. Presentation, discussion, and a worked exercise.

Covers: the principles; the categories of quality risks; how to analyze them; how to align testing with risk levels; how to document the analysis; how to monitor risks during execution; how to report risk-based results.

Two sub-sessions.

The RPN histogram.

Risk Priority Number = Likelihood × Impact. 1 (most risky) to 25 (least risky) on a 5×5 scale.

Common problem: clumping. Shows up when the team skews impact toward worst-case, or when the scale has poorly defined distinctions.

Check: plot the histogram. Fix: refine the scale, re-rate.

The CA histogram.

Allocation of test effort by RPN.

Priority beats expertise assignment.

Previously: tests assigned by tester expertise. Bottleneck every time a key person was out.

Under risk-based testing: priority by RPN. Bottlenecks went away. High-priority tests ran early. Low-priority tests ran later.

Bug management also changed. Severity augmented with risk prioritization. Fix-time focused on the high-risk defects.

What the pilot delivered.

• Intelligent effort allocation within the constraints the project actually had.
• Priority-order bug discovery that optimized every fix-time window.
• Flexible handling of reductions in time or resources.
• Optimized quality within the constraints, not in spite of them.

On the method.

• Coverage is always zero. The honest question is how you select.
• Four benefits, not one. Find severity-first. Minimize residual risk. Know real-time risk. Cut in reverse order.
• Run analysis as a workshop. Whiteboards, sticky notes, business + technical + test.

On running it.

• Plot the RPN histogram. If it clumps, the scale is wrong — not the product.
• Map risks to specs and tests. Traceability cuts both ways.
• Priority beats expertise assignment — routes around every bottleneck.

Release when the risk of delay balances the risk of dissatisfaction.