English | EN 
Let’s be honest—“RISK” is one of those terms that gets thrown around in software testing. But when you strip away the hype and jargon, it’s actually quite straightforward. Risk is the possibility that something might go wrong, and if it does, how serious the consequences would be.
In testing, we typically assess risk by considering two key factors:
- Likelihood – how probable it is that the event will occur
- Impact – how damaging it would be if it did
Once a risk materialises, say, the website crashes on launch day, it’s no longer a risk. It becomes an issue, and the focus shifts from prevention to urgent resolution.
Not all risks are created equal. Some are minor and unlikely to cause significant harm such as a typo in a training manual or a slightly misaligned button. These are the paper cuts of the testing world, irritating, but rarely critical. Then there are the extreme cases. Consider the risk of a meteorite hitting Earth, or the scenario described in The Future I Saw by Ryo Tatsuki, where a small tectonic shift triggers a devastating tsunami. It may sound far-fetched, but if it were to happen, the consequences would be catastrophic.
In software terms, this could be likened to a dormant security flaw in a critical financial system. It might seem unlikely, but if exploited, it could destroy trust, cause financial loss, and damage reputations beyond repair. And then there are the risks that are both likely and severe, the ones that genuinely keep you up at night. A good example is failing to apply a critical security patch. It might not sound dramatic, but the fallout could include data breaches, regulatory fines, and a flood of customer complaints.
We test because of risk. It’s a bit like the principle of “trust but verify.” If there is no meaningful risk or if the worst-case scenario is merely a minor inconvenience, then why invest time and money in testing? No testing is required if the solution poses no risk. It may sound bold, but it is true. If a system can fail without anyone noticing or caring, there is little justification for extensive and expensive testing. However, most systems are not that forgiving. If your application controls air traffic, manages banking transactions, or handles prescriptions, there is no room for error. In these high-stakes environments, testing is not just advisable, but it is absolutely essential.
When people talk about risk in testing, they often focus on functional bugs, broken features, confusing workflows, or anything that disrupts the user experience. These are important, as a bug that prevents customers from completing a purchase is a direct hit to revenue. However, there are other, often overlooked, risks that can be just as damaging:
- Missing documentation, which turns routine maintenance into a guessing game
- Skipping penetration testing, leaving systems vulnerable to cyberattacks
- Neglecting performance testing, resulting in systems that buckle under real-world usage
Each of these risks requires a different testing approach. Focusing solely on functionality is like checking your car’s paintwork before a long journey, while ignoring the brakes.
Traditional risk-based testing often follows a familiar pattern: review the requirements, assign priorities, and tick the boxes. You might use MoSCoW prioritisation i.e. “Must, Should, Could, Won’t” to guide the efforts. While this can be helpful, it often overlooks risks that are not explicitly documented. Things like technical debt, regulatory blind spots, or rapidly shifting market demands can easily slip through the cracks. That’s why I always recommend early and open conversations with stakeholders. Walk them through the test strategy. Ask the difficult questions. Understand their appetite for risk, whether they prefer a cautious approach or are more comfortable with calculated risks.
In an ideal world, we would test everything thoroughly before release. But in reality, deadlines loom, budgets are tight, and test environments have a habit of vanishing or sharing with other projects just when you need them most. So, we prioritise. Sometimes, we accept certain risks. Sometimes, we even test in production. This is not ideal, but it is often the most practical option, as long as the trade-offs are understood and managed. Ultimately, risk-based testing is not about ticking boxes or following a rigid process. It’s a mindset and is about constantly asking:
- What could go wrong?
- Can we afford it?
- What matters most to the business?
Testing is not just about proving that something works. It’s about helping the business succeed safely. That means protecting what matters, whether it is uptime, data privacy, or your organisation’s reputation. So, the next time someone asks why we test, tell them it is to stop a typo from becoming a tsunami. Because in the end, we are all in the business of managing risk, whether we realise it or not.
The future I see for testing is one where we move beyond rigid frameworks and checkbox exercises. It is a future where testers are seen not just as bug hunters, but as strategic risk advisors, the people who understand the business, the technology, and the consequences of failure. Risk-based testing, when done well, is not about doing less, it is about doing what matters most. It is about being pragmatic, asking the right questions, and making informed decisions that balance quality, speed, and cost. Testing is no longer a back-office function. It is a critical enabler of business resilience. And as testers, we have a unique opportunity to shape that future by embracing a smarter, more holistic approach to risk.