Defining risk - ISO 31 000 doesn't make it any clearer
Thoughts for software quality and testing
Published 12:10, 05 January 12
We all know about project risk, risk lists, risk probability and enterprise risk management, etc. But do we really understand what a risk is exactly? Although we hear about risk all the time (and testers are continuously uncovering new risks), a concrete definition seems difficult to pinpoint. On closer examination, there are several contradictory definitions, and the new ISO 31 000 does very little to clarify risk any further, so I’m going to try to elaborate on risk definitions in this post.
Let’s start with everyday risk: Is the risk of flying from London to Edinburgh greater than the risk of going for a walk? Most people would say that flying is riskier. But in reality, the likelihood of something happening to me on 1,000 walks (e.g. sprained ankle, broken leg) is greater than during 1,000 flights. Air travel is considered risky as the consequences of an error leading to a crash, unfortunately, are often deadly.
What about car vs. air travel? What’s riskier? Taking a flight to Edinburgh or driving to Edinburgh? This isn’t as clear cut as walking vs. flying, as a car accident can also cause serious damage. This is where the higher number of car accidents combined with less serious injuries (a car accident is not always fatal) appears to even out the risk of the lower probability of airplane crashes, but the fatal nature of them.
So how does daily life help us to understand risk?
We tend to define risk in terms of the likelihood of the risk occurring and the impact of its consequences, should it occur.
- Risk looks into the future. After a plane or car crash, I am no longer at risk. The same is true after I’ve broken my leg. In these cases the risk of actual damage / loss is gone.
- Risk is uncertain: If damage is inevitable it’s no longer considered a risk. I'll be dead in 100 years, that’s inevitable, so there’s no risk involved.
- Risk often has negative consequences: the fact that there will be a cloud in the sky tomorrow is not a real risk since there is no real negative impact. However, if it rains tomorrow, that poses a risk for someone who plans a BBQ.
All three statements are valid for testers as well: the test before an application is deployed, so testers look into the future. If a tester identifies a defect, it still has a level of uncertainty because it is unclear if an end-user uses the exact tested use case with exactly the same data to force the error, and of course detected errors have negative consequences.
The new ISO 31000 deals explicitly with risk management and here is its definition of risk:
The team behind the certification use the word "uncertainty". Any certain act, is therefore no longer a risk.
I find it questionable, however, to always associate “uncertainty” with risk. By ISO 31 000’s definition, it would be a risk to win the lottery tomorrow.
Another question when defining risk is: what is the unit of risk? If risk is the outcome, then perhaps the unit is monetary? And how do I distinguish different outcomes with degrees of severity (fracture vs. death?).
I think there are better definitions of risk. My favourite is from Doug Hubard:
Examples of uncertainty include: my plane arriving in Edinburgh, since there is always the possibility of it crashing.
Building on Hubard’s definition:
Risk: A state of uncertainty where some of the possibilities involve a loss, catastrophe, or other undesirable outcome.
While playing the lottery is uncertain, at least buying a lottery ticket is no longer a risk if using Hubard’s definition. Unfortunately, this definition also has no units (it’s hard to pin a unit to the word "state"). But at least it allows the use of probabilities to get to a figure for negative impact (eg £) by using this equation:
uncertainty (per cent) * effects of the damage (loss, catastrophe, etc.)
With all this in mind, I wonder what the risk of ISO 31000’s imprecise definition of risk is?
Posted by Frank Simon, head of Research and Innovation at software testing and quality management company SQS