Did you read the scrum guide? I did, multiple times in English and Dutch. I found lot’s of great insights to shape how I approach teamwork and communications. But do you know what I didn’t find? Any reference to a Risk Based approach. And any sane quality professional knows that risks are to be addressed to end up with a quality solution.
The thing to say on the top of your voice is: “No Risk, no Test”. This is what we learn from Risk Based Testing. But what “kind” of testing is Agile testing then? I translate it more like Requirement Based Testing, especially in the scrum implementation of most of my clients. Okay, the risks may come up in conversations in scrum utopia but they are not structurally adressed. So how do we take both the requirements and the risks into account structurally? The same way we did before Agile came in existence, with Risk & Requirement Based Testing – RRBT for short. But we do need to freshen it up a but to work in our Agile world.
Let’s start with the basics, what is a product risk? It is defined as: “The likelihood that a product fails in relation to the conceivable damage when a product fails in production.” And we want to tackle that risk with some form of test. We use a Product Risk Analyses for that. A PRA is defined as: “A process or method to analyse the risks to the product, with the intention to utilize the testing effort in the most valuable way.” But now comes the magic, RRBT gives us a revealing truth… A Product Risk can not exist without a Requirement and vice versa. Think about it, why would you make something if it doesn’t address any risk? You should end up scrapping the requirement or you missed a Risk in your analyses. And let’s say that you defined a product risk but there is no requirement that addresses it? You would be handing the quality of your solution over to pure chance.
The method I now use consists of the following phases and steps:
- Gather Risk Items
- Plot relationship between Risk Items
- Calculate and Classify Risk Items
- Differentiate the work
Gather Risk Items
In this phase we try to do two things: We gather the requirements and we gather the product risks. The requirements are the normal User Stories we know of Scrum and will probably be available already. You do need to check if they are good, that means: independently Designable, Codeable, Testable and Acceptable. Keep in mind that you need to order these Requirements with Moscow for instance. I don’t use the Won’t so I have a three level ordering. See it as High, Medium and Low priorities. Then we try to find all the product risks via interviews and workshops with which we go further in the next phase.
Plot relationship between Risk Items
We can do the RRBT magic now, where we check if every Requirement has a corresponding Product Risk and vice versa. We build a kind of traceability matrix in this process in which we can clearly mark the relationships between all the Requirements and Product Risks.
Calculate and Classify Risk Items
We use a Product Risk Analyses as the basis to calculate and classify the risk items. I find PRISMA a good method where we try do deconstruct risk as likelihood and impact factors. I use that as a basis, I only differentiate from the classification. I don’t use quadrants but I use a High, Medium Low classification. But we only have half of the work done.
You can see what I do in the image to the left. I use the classifications of the Requirement and the Product Risk to classify the relationship itself. I do give more weight to the Product Risk as you can see.
Differentiate the work
Now we have classified the relationships the traditional Test Management job is done. Next step is communicating the work to the team so they can act on it. The image on the right is a quick example of how this can look. In the above right you see what the team should do differently for each classification. A good example is how we differentiate regression testing. For Low we choose not to do any regression testing. For Medium we do a regression test every time we do a release. For High we do a regression test every sprint as well as every release.
Read on?
So with this little summary I tried to give you a little more insight in how I incorporate Risk & Requirement Based Testing in Scrum projects. I wrote an article about it in Dutch which you can find here. I gave multiple presentations about it as well which you can find here. So check them out if you want to know more. Contact me if you have any questions.
Tune in next week for: Leadership for Scrummies
brambronneberg 