Priority and residual risk | Test Analyst: analysis, design, and prevention

Concept and mechanism

Test prioritization requires distinguishing failure likelihood from its consequences. In a fictional example, an infrequent calendar change may apply an incorrect settlement date to many instructions. A frequent visual sorting failure may be easy to recover from. Usage frequency alone does not determine which risk deserves deeper investigation. Gather business examples, incident history, technical changes, and support information to justify estimates. If the organization uses qualitative scales from one to five, multiplying those numbers can support ordering under the adopted convention; it does not automatically convert the assessment into expected financial loss. Record uncertainty and assumptions so new evidence can change priority.

Guided application

Risk reduction depends on test relevance and evidence quality, not merely execution count. If a calendar rule changed, combine boundary values, journeys using artificial holidays, and regression of functions consuming the date. A discovered failure may justify revisiting risks previously considered low. With two hours remaining, protect the highest-impact behaviors first and state what remains uninvestigated. The analyst recommends coverage and presents findings; residual-risk acceptance belongs to the role holding defined project authority. Avoid declaring zero risk because every planned case passed: the plan may have omitted the condition that would cause failure.

IN PRACTICE

An infrequent failure can deserve priority because of its impact.

Common pitfalls

Count treated as risk reduction; ordinal treated as probability; acceptance without authority.

Related topics: Analysis and evidence in the test process · Domains, boundaries, and combinations · States, CRUD, and journeys

Take this idea with you

Update risk using evidence and communicate gaps.

Create account

Reference: ISTQB CTAL-TA syllabus · CTAL-TA v4.0 (2025)