Risk-based testing: you cannot test everything

Here is a truth that surprises new testers: you can never test everything. Even a modest app has more input combinations, paths and states than anyone could check in a lifetime — the number is effectively infinite. So testing is not about coverage of everything; it is about spending your limited time where it matters most. That is risk-based testing, and it is the judgement that separates an effective QA from one who tests busily but in the wrong places. This lesson is how to decide what to test, given you cannot test it all.

Why you cannot test everything

Consider one AgentPay form: an amount, a phone, a type, an agent. Amount alone has billions of possible values; combine it with the other fields, with different users, different states (agent active or suspended), different sequences, different devices and networks, and the combinations explode beyond any possibility of exhaustive testing. This is not a failing of your process — it is a mathematical fact about software. Anyone who says "we tested everything" either has a trivial system or does not understand the problem.

The consequence is liberating once you accept it: since you cannot test everything, testing is a series of choices about what to test and what to skip. Testing well means making those choices deliberately and well — not testing more, but testing the right things. The skill is prioritisation.

Risk = likelihood × impact

You prioritise by risk, and risk has two dimensions:

Impact — how bad is it if this fails? A bug in the money-transfer flow (wrong amount, double charge) is catastrophic; a typo on an obscure help page is trivial. Impact is about consequences — to users, to the business, to safety, to trust.
Likelihood — how likely is this to be broken? Newly written or recently changed code, complex logic, areas with a history of bugs, and integrations between systems are more likely to fail than stable, simple, long-untouched code.

Risk is roughly likelihood × impact, and you aim your testing at the high-risk areas: things that are both likely to break and bad if they do. For AgentPay that is unmistakably the money and transaction flow — high impact (real money) and non-trivial (validation, idempotency, permissions, concurrency). You test that thoroughly and from many angles. A rarely used, low-stakes setting gets a light touch. Same time budget, spent where the risk is.

Using risk to plan your testing

Risk-based thinking shapes concrete decisions all through the work:

What to test first and most — the highest-risk areas get the deepest testing and the earliest attention. If you run out of time, you have at least covered what matters most.
What to automate — high-risk, high-repetition flows are prime automation targets (the what-to-automate lesson): risk drives the automation strategy directly.
How much to test something — depth follows risk. The payment flow gets exhaustive boundary and negative and concurrency testing; a static page gets a glance.
Where to focus regression — after a change, test hardest around what changed and what it could affect (high likelihood), and the critical flows (high impact) — not a uniform re-test of everything.
When to stop — you stop testing an area when the remaining risk is acceptably low, not when you have "tested everything" (impossible). Risk gives you a principled answer to "is this tested enough?".

This is why the manual-testing module's techniques matter alongside risk: risk tells you where to aim, and equivalence partitioning, boundary values and the rest tell you how to test that area well once you are there.

Communicating risk

A subtle but important part of the job: because you cannot test everything, you must communicate what you did and did not test, and the risk that remains. When a release ships, the team is making a risk decision, and they need an honest picture:

Say what you tested and what you deliberately did not, and why.
Flag the risks you are aware of that remain — "the payment flow is well tested; the new report export is only lightly covered".
Do not imply "all tested, all fine" — that is never true, and claiming it robs the team of a real decision.

A QA's honest read on remaining risk is one of the most valuable things they provide — more valuable than a false "everything passed". The team decides whether to ship; your job is to make that decision informed.

Check your work

You cannot test everything — combinations are effectively infinite (one AgentPay form already has billions of input combinations). This is a mathematical fact, not a process failure. So testing is a series of choices about what to test and skip; the skill is prioritisation, not volume.

Risk = likelihood × impact. Impact: how bad if it fails (money flow catastrophic; help-page typo trivial). Likelihood: how likely to be broken (new/changed/complex/integration/history-of-bugs code is riskier than stable simple code). Aim testing at high-risk areas — AgentPay's money flow above all.

Risk drives decisions: what to test first/most (deepest on highest risk), what to automate (high-risk high-repetition), how deep (depth follows risk), where to focus regression (around changes + critical flows), and when to stop (remaining risk acceptably low, not "everything tested"). Risk says where; the manual techniques say how.

Communicate risk: state what you tested and did not and why; flag remaining known risks; never imply "all tested, all fine" (untrue, and it robs the team of a real ship decision). An honest remaining-risk read is more valuable than a false "all passed".

Practice

Estimate the number of test cases to exhaustively test one AgentPay form, and explain why exhaustive testing is impossible.
Rank five AgentPay areas by risk (likelihood × impact) and justify which you would test most.
Explain why the money/transaction flow is the highest-risk area and how you would test it deeply.
Given a change to the transactions list, describe a risk-based regression plan (not a uniform re-test).
Answer "is this feature tested enough?" using remaining risk rather than "everything tested".
Write a short honest release-risk summary for a feature: what you tested, what you did not, what risk remains.

Official documentation

Ministry of Testing — Risk-based testing — Prioritising testing by risk.
ISTQB — Foundations / risk and testing — Risk, likelihood and impact in a testing syllabus.
Google Testing Blog — Practical prioritisation of testing effort.

Next: test metrics that matter, and vanity metrics that do not.