A couple or so days ago, I came across a tweet by @dailytestingtip.
Risk is a problem that might happen. James Bach http://ow.ly/1s4j1 #softwaretesting
The link lead to a pdf file on Heuristic Risk-Based Testing by James Bach. One of the things discussed in the paper was the two approaches to analysis.
- Inside-Out – wherein you chop things up to smaller components, look into each one of them and ask What can go wrong here?
- Outside-In – wherein you’ve got a list of known or possible risks, look at each one of them and ask Does and will this risk apply?
As I read the description for the first approach, I recognized it as the approach I had taken for planning for my testing of a particular function in a recent project. I find it cool when what I’m doing turns out to have some official/legit-sounding name. Hey, I wasn’t just planning… I was doing inside-out risk analysis!
What I basically did was I diagrammed my understanding of the functional specs in an excel file capturing actions that the user could do (e.g., Click button A, Click button B) and the corresponding program behavior for the action. For the program behavior, I tried breaking it down into the steps that would need to be performed (e.g., for Click button A, the program will have to do Actions 1, 2 and 3). Then for each step, I tried to think of what if’s to ask which in a way was asking what can go wrong for the particular step.
My resulting informal test plan looked like something like the table depicted below. Since I used excel, I used another column to track whether I’ve gone through the cases or if there were some problems encountered.
One of the lessons I learned (as far as inside-out risk analysis is concerned) from reading the article is that the approach I took could have been done together with the developer. Two heads would have been better than one. Another thing is the use of more elaborate guide questions compared to my very generic “think of what if’s or things that could go wrong”. James Bach gave three questions we can ask for each part of the product:
- Vulnerabilities: What weaknesses or possible failures are there in this component? [my take: what weaknesses are there at this point?]
- Threats: What inputs or situations could there be that might exploit a vulnerability and trigger a failure in this component? [my take: how could we attack these weaknesses to trigger the things that could go wrong?]
- Victims: Who or what would be impacted by potential failures and how bad would that be? [my take: what happens when things have gone wrong, consider error handling, recoverability]
testkeis 