Risk-Based Testing: Decide What to Test First
By Xusheng YangYou have an hour to check a release containing a billing refactor, a new search filter, and a settings-page spacing change. Running tests in alphabetical order is easy, but it does not explain why the most consequential behavior was checked in time.
Risk-based testing allocates attention according to what could go wrong, how harmful it would be, and what makes that failure plausible. It also makes untested uncertainty visible to the person deciding whether to release.
This is part 12 of Testing Methods in Practice. The release and time budget below are planning examples, not evidence about any deployed HiTest version.
Describe failures in business terms
Replace “billing is risky” with a concrete outcome: an upgrade charges a customer but does not grant access. Replace “search changed” with a consequence: a workspace filter exposes another workspace's records.
Include data exposure, financial loss, blocked work, recovery difficulty, and affected users. A rare irreversible failure can deserve priority over a frequent cosmetic defect. Frequency alone is not the ranking.
Risk management and test prioritization are part of ISTQB's Foundation Level framework. The worksheet below is a practical local planning aid, not an official universal scoring formula.
Use a short, reviewable worksheet
| Possible failure | Impact | Why plausible in this release | First evidence to obtain |
|---|---|---|---|
| Paid upgrade leaves access unchanged | High | Entitlement mapping was refactored | Sandbox upgrade and independent entitlement read |
| Search returns foreign-workspace records | High | Shared query filters changed | Server isolation checks plus representative browser view |
| New filter loses state on pagination | Medium | URL serialization changed | Apply filter, change page, reload, inspect results |
| Settings heading wraps awkwardly | Low for this example | Typography tokens changed | Narrow-viewport visual check |
The labels summarize judgment. Add evidence behind them: changed files, affected contracts, previous incidents, or unfamiliar dependencies. A High/Medium/Low table with no reasons is difficult to review and easy to game.
Consider the change's reach and your uncertainty
A two-line shared permission change can affect more users than a new isolated page. Trace dependencies, affected roles, old data, and external services before deciding the scope.
Treat uncertainty as a reason to investigate, not as proof that failure is likely. If nobody understands the migration path for existing subscriptions, allocate time to resolving that uncertainty and testing an existing-record fixture.
If a proposed check cannot run because a sandbox is unavailable, record the blocker and the risk it leaves open. Do not replace a payment test with a screenshot of the pricing page and call the same risk covered.
Build a feasible execution plan
For the one-hour example, prepare accounts and fixtures first. Run the targeted service checks for entitlement and workspace boundaries, then execute the browser journeys that connect those rules to user behavior. Leave time for inspecting failures and a release decision.
Use the time budget to select evidence, not to rush through a large list. Three well-chosen checks with inspectable results can be more informative than twenty cases whose failures nobody has time to examine.
Keep risk priority and execution cost separate. A cheap low-risk check can run while a critical integration check prepares, but it should not displace that check in the release decision. The test-layer guide helps place checks where they can observe the required behavior efficiently.
State completion in terms of risks covered
A release note should say which build, environment, roles, and data states were checked. For each major risk, link the relevant evidence and any unresolved issue.
For example: “The sandbox upgrade granted the expected entitlement to an existing paid account. The duplicate-event integration case passed. Cancellation recovery remains blocked because the provider sandbox is unavailable.” This is an example report format, not a claim that those checks ran here.
The decision maker can then accept the remaining risk, reduce scope, or delay. A test-count percentage cannot substitute for that context.
Revisit priority when evidence changes
If a supposedly isolated style update hides the primary action on mobile, increase its priority based on the observed impact. If a risky dependency is removed from the release, revise the plan accordingly.
Your exercise: list five concrete failures for your next release. Rank their impact and explain their plausibility. Select the first three checks, name their evidence source, and identify one risk that will remain unverified. Compare the result with the existing SaaS regression checklist to ensure prioritization has not erased essential baseline coverage.
Next in the series: Acceptance criteria to test cases.