Risk-based testing prioritizes testing effort by the risk each area carries — the probability of failure multiplied by the impact of that failure — so that when time is limited (which is always), the most important things are tested first and thoroughly, and low-risk areas get proportionally less.
You can never test everything, and under deadline pressure the question is not 'how do I test it all?' but 'given limited time, what testing gives the most risk reduction?' Risk-based testing answers this by ranking areas on two dimensions: likelihood of a defect (complex, new, frequently-changed, or historically buggy code is higher) and impact if it fails (revenue, data integrity, security, many users, legal — higher). High-likelihood × high-impact areas get the most rigorous testing; low × low areas get light or deferred coverage. This lets QA give a defensible answer under pressure: not 'we tested everything' (false) or 'we ran out of time' (unhelpful), but 'we focused on the highest-risk areas — payments, auth, data integrity — and here's the residual risk in the lower-priority areas we sampled or deferred.' It reframes testing from an impossible completeness goal to an optimization that maximizes confidence per unit of time, which is exactly the judgment interviewers want to see.
Given one day to test a release touching checkout, a help-text tooltip, and a footer link, QA spends the bulk of the time on checkout (high likelihood of change impact × high revenue impact), briefly smoke-checks the tooltip, and defers the footer link — then reports exactly that coverage and residual risk to the PO.
RISK-BASED TEST PLAN — 1 day available
Area Likelihood Impact Risk Effort
-------------- ---------- -------- ----- ---------------------
Checkout/pay High High HIGH Deep: happy+negative+DB
Login/auth Medium High HIGH Core paths + lockout
Search filters Medium Medium MED Key paths, sample edges
Profile edit Low Medium MED Smoke
Help tooltip Low Low LOW Quick glance
Footer link Low Low LOW Defer / spot-check
Report to PO: HIGH areas fully covered; LOW areas sampled/deferred;
residual risk concentrated in deferred LOW items only.Scenario: A release is happening in one day and there's no way to fully test everything that changed. The PO asks 'can you just make sure it all works?' How do you decide what to test, and what do you tell the PO?