Risk Management
Product risk drives what you test. Project risk drives when you test it. A Test Lead who cannot quantify risk is just guessing at priorities.
1 The Hook — Why This Matters
In 2020, an Auckland fintech startup launched a new payment feature three days before a public holiday weekend. The team knew data migration was complex, but everyone was focused on the shiny new UI. The data migration had never been dry-run at production scale.
On launch day, transactions duplicated. Customers were charged twice. The rollback took six hours because there was no rollback plan in the risk register. The company processed $2.3 million in erroneous charges, spent three weeks on reconciliation, and lost their largest merchant account.
The risk was visible to anyone who looked. But there was no risk register, no exposure scoring, and no mitigation owner. As a Test Lead, your job is to make risks visible, quantified, and owned before the code ships.
2 The Rule — The One-Sentence Version
Allocate testing effort proportionally to risk exposure, and never let a high-risk item ship without a named owner and a mitigation plan.
Risk exposure = Likelihood × Impact. If you test everything equally, you are under-testing the dangerous parts and over-testing the safe parts. Risk-based testing is the discipline of deliberate imbalance.
3 The Analogy — Think Of It Like...
A hospital triage nurse on a busy Friday night.
The nurse doesn't treat patients in arrival order. A sprained ankle waits. Chest pain goes straight through. Triage is the discipline of sorting by severity and probability of harm, not fairness. Risk management in testing is the same: the payment engine is chest pain, the About page is the sprained ankle. Treating them equally isn't fair — it's negligent.
4 Watch Me Do It — Step by Step
Here is how to build and use a risk register for an NZ financial services project. Follow these steps for any release you lead.
- Identify risks — product and project Product risk: what could fail in production? Project risk: what could delay or block delivery? Brainstorm with the whole team. No risk is too small to record at this stage.
- Score likelihood and impact (1–5) Use a consistent scale. Likelihood: 1 = rare, 5 = almost certain. Impact: 1 = negligible, 5 = catastrophic. Multiply to get exposure (1–25).
- Build the risk register Columns: Risk ID, Description, Category, Likelihood, Impact, Exposure, Mitigation, Owner, Status.
- Choose mitigation type Reduce (test more), avoid (remove feature), transfer (insurance or third-party SLA), or accept (document and monitor). Default to reduce for high-exposure items.
- Allocate effort by exposure The highest exposure gets the deepest testing, the most senior tester, and the earliest time in the schedule.
- Review and update continuously Risks change. A third-party API that was stable last sprint may have a new deprecation notice today. Review every sprint.
| Risk | L | I | Exp | Mitigation | Owner |
|---|---|---|---|---|---|
| Payment processing failure | 5 | 5 | 25 | Dedicated test team, contract testing with Stripe/POLi, load testing | Test Lead |
| Data migration error | 5 | 4 | 20 | Dry run, reconciliation scripts, rollback plan | Data Engineer |
| Third-party integration outage | 3 | 5 | 15 | Sandbox testing, fallback logic, service virtualization | Tech Lead |
Senior engineer insight
The shift that changed how I approach risk management was realising that the risk register is primarily a communication tool, not a testing tool. Once I started presenting exposure scores in stakeholder reviews — not just bug counts — conversations about schedule trade-offs became concrete. A product owner who balks at "we need two extra days on the payment engine" will not balk when they see Exposure: 25 next to it and Exposure: 3 next to the feature being de-scoped. Numbers give you leverage that opinions never will.
The most common mistake Test Lead testers make here is building a thorough risk register at kick-off and then never opening it again — so by release day it describes a product that no longer exists.
5 When to Use It / When NOT to Use It
✅ Use risk-based testing when...
- Time or budget constraints force prioritisation
- The system has high-impact failure modes (finance, health, safety)
- You need to justify test coverage decisions to stakeholders
- Multiple features compete for the same testing window
- You have historical defect data to calibrate scores
❌ Don't rely solely on risk when...
- Regulatory compliance mandates uniform coverage
- The team lacks data to score likelihood accurately
- Risk scores become political rather than evidence-based
- Low-risk areas have never been tested and are unknown territory
- The register is created once and never updated
From the field
On a Wellington-based government portal project — an agency migrating citizen services to a new platform — the team classified data sovereignty and hosting location as a "low likelihood" risk because the infrastructure decision had already been made. What they hadn't validated was that the hosting provider's NZ-region nodes were shared with commercial tenants in ways that conflicted with NZISM Tier 3 requirements for handling personally identifiable information. The Test Lead had a product risk register but no project risk register, and no column for regulatory exposure. During penetration testing in UAT, the assessor flagged the misconfiguration. The go-live was pushed six weeks while the agency renegotiated hosting and re-ran security testing. The lesson that generalises: for any public-sector NZ project, NZISM risk tiers must appear in the risk register as a named category from day one — not as a compliance sign-off at the end.
Before you build a risk register, ask:
- Do you have defect or incident history to inform likelihood scores, or are you guessing?
- Can you describe each risk in one sentence, and can stakeholders agree on what it means?
- Will the team actually use the risk register to prioritise testing, or is it a compliance checkbox?
- Who owns updating the register as the product evolves—is that person accountable?
6 Common Mistakes — Don't Do This
🚫 Treating the risk register as a one-time activity
I used to think: once risks are identified at kick-off, the job is done.
Actually: Risks are living things. A stable third-party API can release a breaking change overnight. A risk register that hasn't been updated in three sprints is a work of fiction. Review it every sprint, link it to sprint goals, and update statuses after every incident.
🚫 Ignoring business risks in favour of technical risks
I used to think: risk management is about code complexity and integration points.
Actually: Business risks can be worse. "We miss the regulatory filing deadline" is a project risk with exposure 25, even if the code is simple. Involve the product owner and compliance officer in risk identification. Testing doesn't exist in a technical vacuum.
🚫 Equal effort regardless of risk score
I used to think: fairness means every feature gets the same number of test days.
Actually: Equal effort is unfair to the user. A payment bug affects thousands. An About-page typo affects nobody. Risk-based testing deliberately allocates more effort to high-exposure items. If your plan shows identical test days for every feature, you are not doing risk-based testing — you are doing hope-based testing.
When this technique fails
Risk-based testing fails when risk scores become political: management inflates likelihood to justify preferred priorities, or testers ignore the register because it does not match reality. It also fails when low-risk areas are never tested—and then they harbor the bug that breaks production. Finally, a risk register created once and never updated becomes worse than useless: it is a false confidence.
7 Now You Try — Risk Scoring Exercise
Scenario: An NZ ecommerce platform is adding a "buy now, pay later" integration with a new third-party provider. The provider has no sandbox environment and their documentation is two weeks out of date. The feature must ship before Black Friday.
Question: Score Likelihood (1–5) and Impact (1–5) for "Integration behaves differently in production than in testing." Then state the mitigation type.
Likelihood: 4, Impact: 5, Exposure: 20
No sandbox means you cannot verify behaviour pre-production. Out-of-date documentation means your tests may be based on incorrect assumptions. This is a near-certain, high-impact risk. Mitigation type: Reduce (contract testing against their staging endpoint, canary release with limited users, comprehensive monitoring and automated rollback) plus Transfer (penalty clause in the commercial agreement for integration failures). A Test Lead who misses this risk is gambling with Black Friday revenue.
Why teams fail here
- Risk scores are assigned by the Test Lead alone — without developer, ops, or product input — so whole categories of risk (infrastructure fragility, business deadlines, regulatory exposure) are systematically missed.
- Likelihood scores drift toward optimism: teams score known stable components at 1 without checking whether those components have changed, been upgraded, or acquired new dependencies since the last release.
- The register conflates product risk and project risk in a single undifferentiated list, so mitigation strategies are incoherent — you cannot "test more" your way out of a resource shortage or a public holiday deployment window.
- Accepted risks are documented once and never reviewed again — in NZ government projects especially, an "accepted" NZISM Tier 2 risk that was valid in Sprint 1 may be a compliance breach by Sprint 8 if the data classification of what the system handles has changed.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready for practice.
Q1. What is the difference between product risk and project risk?
Product risk is what could fail in the live system (bugs, downtime, data loss). Project risk is what could delay or block delivery (resource shortage, environment unavailability, scope creep). Both drive testing, but in different ways: product risk shapes depth of coverage; project risk shapes schedule and contingency.
Key takeaway
A risk register that nobody updates is not a safety net — it is a paper alibi for a decision nobody made consciously.
Q2. What are the four mitigation types, and when would you use "accept"?
Reduce (test more), avoid (remove the feature), transfer (insurance or third-party SLA), and accept (document and monitor). You use "accept" when the cost of mitigation exceeds the potential impact, or when the risk is so unlikely that active mitigation is not economically rational. Acceptance must be documented, signed off, and monitored.
Q3. Why should the whole team be involved in risk identification, not just the Test Lead?
Because no single person sees every risk. Developers know code complexity and dependency fragility. Product owners know business deadlines and regulatory pressure. Ops knows environment instability. Security knows threat surfaces. A risk register built by one person is a risk register with blind spots. Collaboration produces better coverage and shared ownership.
9 Interview Prep — Lead-Level Q&A
Q. How do you handle a high-risk item that stakeholders want to skip testing?
I document the risk formally in the risk register with its exposure score, the stakeholder's request, and the potential business impact. I then propose mitigation alternatives: reduced scope, canary release, enhanced production monitoring, or phased rollout. If the stakeholder still wants to proceed, I request written sign-off acknowledging the accepted risk. The goal is not to win every argument — it is to ensure every risk decision is conscious, documented, and owned.
Q. Walk me through how you build a risk register from scratch.
I start with a cross-functional workshop: dev, test, product, ops, security. We brainstorm product risks (what could fail) and project risks (what could delay). Each risk gets a unique ID, description, category, Likelihood score (1–5), Impact score (1–5), and Exposure (L × I). We then assign mitigation strategies, choose mitigation types (reduce, avoid, transfer, accept), name an owner, and set a review cadence. The register lives in the team's shared workspace and is reviewed every sprint. I also use historical defect data to calibrate likelihood scores rather than relying on gut feeling.
Q. How do you justify risk-based testing to a stakeholder who wants 100% coverage?
I explain that 100% coverage is often economically irrational and sometimes technically impossible. I present the risk register, show the exposure scores, and demonstrate how effort maps to risk. "We are testing the payment engine for two weeks because its exposure is 25. We are testing the footer link for two hours because its exposure is 2." I also cite historical data: "Last quarter, 80% of production issues came from high-exposure areas. Risk-based testing targets where the bugs actually live." If regulatory compliance mandates full coverage, I separate compliance coverage from risk-based depth and budget for both.
Q. Give an example of when you updated a risk register mid-sprint.
During a sprint for an NZ insurance platform, our third-party identity verification provider announced a breaking API change with one week's notice. The risk was not in our original register because the provider had been stable for months. I called an emergency risk review, scored the new risk (Likelihood 5, Impact 4, Exposure 20), added mitigation steps (contract testing against the new schema, fallback to manual verification, daily check-ins with the provider), and reprioritised sprint tasks to allocate two days of tester time to the integration. The register update meant the team had a plan instead of a panic when the change landed.