Prioritizing product risk

Testing time is limited, so every feature cannot receive identical effort. Priority begins with product risk: the chance of a failure in a particular use and its impact if it happens. Multiplying two labels does not turn them into measured probabilities. A rating scale is a way for a team to agree on an order, and the order changes with usage evidence, defect history, and the users affected. A delayed button color differs from charging twice. Yet a display fault may become serious if it prevents a keyboard user from completing an essential booking. Name the affected person and condition, not merely the feature.

Describe an unwanted event rather than assuming its cause. “A retry records two charges” can be tested. “The developer forgot deduplication” is a causal hypothesis. Consider evidence for likelihood: did the payment route change, does it depend on another service, have related failures occurred, and how often is the route used? If usage is unknown, mark likelihood uncertain; do not invent a frequency. For impact, examine money, data, service interruption, and whether the consequence can be reversed. If the number of affected people matters, use a valid source for that number.

A small team can use a descriptive scale from one to three for impact and one to three for likelihood. Define the categories before assigning ratings. Impact three might involve a financial loss or data exposure; impact one could be limited inconvenience that can be corrected. Likelihood three might mean repeated failure in relevant test data or extensive change without adequate checks, not merely a strong feeling. The product of ratings gives an approximate ranking; it is not a real-world probability or monetary estimate. Keep reasons for disagreement. A disagreement may reveal that the team does not know how a network timeout affects retries.

Turn the ranking into tests. For a higher risk, prepare a normal, boundary, and relevant failure case, then choose a test level that can expose the consequence. In payment, test a fixed idempotency key through an API and inspect transaction records; also examine what a user sees when the reply disappears. Pressing twice and seeing only one message does not establish that only one transaction was recorded. A lower risk may need a narrower interface check for this release. State which tests are deferred and what remains unknown. A long list is not proof of complete coverage.

Risk changes during the work. A repair to duplicate charging might alter refund calculation. Adding a mobile channel can create another retry path. Review the risk register and associated cases when a relevant change arrives. An open defect does not vanish because unrelated cases pass. The specialist presents the risk, evidence, tests, and options; the product and accountable decision owners accept remaining exposure or defer release. A single rating does not decide a release by itself. Open defects, the scope of actual testing, and operational controls also matter.

Update an estimate when evidence arrives. A reliable lab log showing a failure on two of twenty simulated retries demonstrates occurrence in those simulations, not a ten percent failure probability for every customer. If all simulations used an artificially slow network, report that condition. The aim is to turn a vague concern into a reviewable test decision while preserving sample limits.