The Test Analyst's Tasks in Risk-Based Testing
Product risk drives test effort
Risk-based testing (RBT) is a strategy in which test effort is allocated according to product risk - the risk that the software will fail to deliver expected quality. The test analyst's tasks in RBT are to help identify risks, assess them, define mitigation activities through test design and execution, and monitor how risk changes as testing progresses. Risk identification uses the test basis (requirements, architecture, user stories), domain knowledge, defect history and workshops; the output is a set of risks recorded in a risk register owned by the test manager. Assessment rates each risk on likelihood and impact, and the risk level is usually a product of the two, not a sum. High-likelihood, high-impact risks get deeper coverage, more techniques and earlier execution; low risks get lighter, often experience-based, coverage.
The most common traps are: (1) confusing product risk (quality, e.g., a miscalculated interest rate) with project risk (management, e.g., a late test environment); the test analyst contributes mainly to product risks. (2) Treating the risk level as a sum of likelihood and impact. (3) Forgetting that RBT prioritizes testing rather than reducing it, and that risks must be re-assessed, not frozen at kick-off. (4) Assuming the analyst owns the risk register - that is the test manager's role.
Worked example. In a payments module, "incorrect fee calculation" has high impact (financial loss) and medium likelihood, so it is high risk: use decision tables plus boundary values with high coverage. A misspelled footer label is low impact and low likelihood: use a checklist. Rule of thumb: the depth and technique set for each area should follow its risk level, and every risk should trace to at least one test condition.