LEARN. PRACTICE. GROW.Concept and mechanism
Product risks concern possible product problems such as duplicate debits or unauthorized access. Project risks threaten work execution, such as missing environments, people, or time. A test plan should state objectives, scope, approach, resources, and criteria. Entry criteria help assess readiness; exit criteria support completion assessment. Risk-based prioritization seeks evidence about impact and likelihood while considering dependencies. Management monitors results and adjusts work; a report should show coverage, defects, and remaining risk in a form appropriate to its audience.
Guided application
Before a release, a high pass percentage does not automatically compensate for a critical defect. Explain unmet criteria and options to the designated authority. Do not change severity merely to pass a gate. For each defect, retain version, environment, conditions, steps, expected result, actual result, and evidence without unnecessary sensitive data. Also identify testware versions and data used. This supports reproduction of differences between runs and helps distinguish a real regression from environment or test changes.
98 of 100 tests pass, but the remaining two reveal another customer’s data. The report should highlight this impact and the unmet exit criterion.
Common pitfalls
Confusing priority and severity; hiding unexecuted cases; losing the executed configuration; letting the schedule redefine results.
Related topics: Tools and confidence in the signal · Evidence, defects, and test objectives
A release recommendation should expose evidence and risk still requiring a decision.
Reference: ISTQB CTFL syllabus v4.0.1 · CTFL v4.0; syllabus v4.0.1 (2024-09-15)