QA Engineer interview question
How do you prioritise testing by risk?
Score features by likelihood of failure and impact on users, revenue, safety, compliance and recoverability; add change complexity and defect history, then spend depth and environments where residual risk is highest.
Direct answer
What a strong answer covers
How it works
Risk-based testing spends limited testing effort where failure would hurt most and is most likely. Each feature or area gets a likelihood score from change complexity, code churn, defect history, new technology, and team familiarity, and an impact score from user reach, revenue, safety, compliance, and how hard a failure is to recover from. The product of the two ranks the areas. High-risk areas get deep testing, exploratory sessions, multiple environments, and performance and security attention; low-risk areas get the automated regression suite and nothing more. The scoring is revisited each release because both factors change.
Example
For a release that touched the checkout, a settings page, and a rewrite of the invoice PDF generator, the risk matrix placed checkout first because of revenue and a concurrency change, the PDF generator second because it was new code with no defect history and affected every invoice, and settings last. Testing time was split roughly 50, 35, and 15 percent, and the PDF generator’s exploratory session found a locale bug that the unit tests had not covered.
Common mistakes
- Testing everything equally and running out of time on the risky parts.
- Scoring only likelihood and ignoring that a low-probability failure in billing is catastrophic.
- Setting the risk profile once and never updating it as the code changes.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.