26 Sep Risk Analysis Terms Every Software Tester Should Know and Apply!
The following is a blog based upon the Quality in a Quick video episode “Learning Important Risk Terminology” which aired on YouTube on 6/25/2018
One of my favorite topics, without a doubt, is risk analysis as it’s applied (or should be applied) to software testing. In today’s blog I share some important terminology pertaining to risk analysis that, if you learn and apply, you’ll improve your testing process before you know it!
Let’s start off with the word “risk”. What does risk truly mean? Well, we’re referring to “the potential loss to an organization”. Think about the risk of having a heart attack, or being in a car accident, or having something stolen. When there’s risk, there’s the possibility there’s going to be some type of loss to an organization, or to somebody.
Then there’s “risk event”. A risk event is the actual occurrence of the risk and its impacting the effort, the project, or the organization.
Let’s not forget “risk exposure”. This is the measure of the probability of an event times the loss. The higher the likelihood a bad event will occur times the loss or impact (whenever that bad event does occur) gives you your risk exposure.
And then you’ve got “threat”. The term threat means that it (the threat) is something capable of exploiting a vulnerability. So, a hacker is a threat.
Wait a minute, what about “vulnerability”? That’s the flaw the hacker (aka – the threat) would, or may, exploit. When we’re talking about application software security, an example would be poor coding allowing for SQL injection, a flaw which could potentially be exploited by a hacker, to access data that they shouldn’t have.
“Risk management” is the process to identify, quantify, respond to, and control risk. And I do hope you have solid risk management in place.
“Risk acceptance” is the amount of risk acceptable to the project or to the organization. You’ve identified the risk, you’ve rated it, but… the dollar amount associated with the risk is not specified (perhaps it hasn’t been calculated or it simply isn’t being specified for purposes of “risk acceptance”). Think about it…a lot of retail chains are now utilizing automated cashiers. You, the customer, check yourself out. Obviously, there’s some risk in this automated procedure. There’s theft potential the organization is willing to accept as a risk.
How is “risk appetite” different? Well, risk appetite the (potential) amount of the loss has been determined to be acceptable to management, or to the organization, and a dollar amount has been put to it. In other words, for the automated cashiers’ example, the retail organization has identified a specific dollar amount they’ve deemed acceptable as a loss.
Then you’ve got “inherent risk” – the risk in the absence of action. Often, during a discussion with leadership at organizations, we’ll get into the conversation about the cost of an effort or initiative…the “cost to do something” as I’ll put it. And I remind them that, quite often, there is a greater cost to do nothing. Because doing nothing is a risk.
Another important term to understand is “residual risk”. The risk remaining after the response. In other words, you’ve performed an action to reduce or mitigate the risk but, very likely, some risk remains. So what is that? It’s very important you identify the residual risk.
“Risk mitigation” is the action you’re taking to reduce threats. Perhaps there are certain threats you’ve determined you cannot eliminate and therefore you simply want to reduce. That is risk mitigation.
And then you’ve got “control”. A control is anything that reduces risk. Think about when you visit a website and you get those abstract letters you’ve got to identify and type in before you can proceed. Or a series of photos where you’re required to identify and select all those photos with an automobile in it. That’s a control. It’s purpose? To reduce the risk an automated robot is what’s truly accessing the web application.
I hope you’ve found this helpful. A lot of great terms to understand! Now, it’s up to you to learn further and apply with focus!
If you have any feedback, any questions, or any topics you’d like address in future blogs or “Quality in a Quick” videos, please email me at bcrews@checkpointech.com. I’m Bob Crews, President and Co-Founder of Checkpoint Technologies.
Thank you so much. Make it a great day!
Bob Crews
Email: bcrews@checkpointech.com
LinkedIn: www.linkedin.com/in/bob-crews-checkpointech
