Risk-Based Testing
Decide what to skip. Risk-based testing uses risk exposure to determine what to test first, how deeply to test it, and what to deprioritise when time runs out.
1 The Hook — The "Time" Trap
Imagine you have 10 minutes to clean your entire house before a guest arrives. Do you start by dusting the top of the fridge, or do you clear the clutter off the couch and hide the dirty dishes? You prioritise based on what the guest will actually see and care about.
In software, we never have time to test everything. Risk-Based Testing is the art of deciding which "rooms" to clean and which ones to just keep the door closed on.
2 The Rule — Exposure = Likelihood x Impact
Risk Exposure is the probability of failure multiplied by the damage it would cause.
- Likelihood: How likely is this to break? (Complex code, new features).
- Impact: How much does it hurt if it breaks? (Financial loss, legal breach).
- Priority: Test the items with the highest "Exposure" score first.
3 The Analogy — The Insurance Policy
High Value vs. High Probability.
When you buy insurance, you pay more to protect things that are High Value (Your House) or High Risk (A Teenage Driver). You don't buy "Phone Screen Insurance" for $500/year because the impact of a broken screen is low. Risk-Based Testing is your "Testing Insurance Policy." You spend your "Premium" (Testing Time) on the features where the "Payout" (Risk of Failure) is highest.
4 Watch Me Do It — NZ Payment Portal
Scenario: A NZ government agency is launching a rates payment portal. You have 3 days to test 3 features.
| Feature | Likelihood (1-5) | Impact (1-5) | Exposure |
|---|---|---|---|
| Payment (POLi) | 4 (New Code) | 5 (Financial) | 20 |
| GST Calculation | 2 (Old Code) | 5 (Legal) | 10 |
| FAQ Page | 1 (Static) | 1 (Minor) | 1 |
The Strategy: Day 1 & 2: Full deep testing on Payment. Day 3: Quick check on GST. Skip FAQ entirely if needed. This is a defensible decision.
5 Decision Tool — Product vs. Project Risk
📦 Product Risk (What we test)
- Bugs in code.
- Security leaks.
- Calculations errors.
🗓 Project Risk (How we test)
- Environment down.
- Tester is sick.
- Late delivery.
6 Common Mistakes
🚫 Treating everything as "High" priority
I used to think: Everything is important, so I'll mark it all High.
Actually: If everything is High, then nothing is High. You lose the ability to prioritise. You must force the stakeholders to rank features 1 to N.
🚫 Forgetting Likelihood
I used to think: The Login page is critical (Impact 5), so we must test it for 3 days.
Actually: If the Login code hasn't changed in 2 years, the Likelihood is 1. Your Exposure is only 5. Spend your time on the *new* feature that has Impact 4 but Likelihood 5 (Exposure 20).
7 Now You Try — Score the Risk
Scenario: You're testing a NZ e-commerce app. A new "Apply Discount Code" feature was written by a junior dev (Likelihood 5). If it breaks, users pay full price (Impact 3).
What is the Exposure score?
Math: 5 (Likelihood) x 3 (Impact) = 15.
8 Self-Check
Q1. What is a "Risk Register"?
It is a document that lists all identified risks, their Likelihood/Impact scores, their Exposure, and the "Mitigation Plan" (how you will test them).
Q2. Can testing ever eliminate risk entirely?
No. Testing only **Reduces** risk. There is always a "Residual Risk" (the risk that remains after you stop testing). As a Lead, your job is to make sure the Residual Risk is acceptable to the business.
9 Interview Prep
"How do you justify cutting testing for a feature to a stakeholder?"
Answer: "I use the Risk Register. I show them that we have 100 hours of testing but 150 hours of work. I show them that Feature A has an Exposure of 25 while Feature B is only 5. I then say: 'To ensure Feature A is safe, we have decided to defer Feature B. Do you agree with this risk trade-off?' This makes it a business decision, not a 'lazy tester' decision."
10 Next Step
You've prioritised the risks. Now, let's figure out how long it will take to mitigate them. Next: Test Estimation.