Chris Dabnor
09/01/20
People
Risk Storming
At Codeweavers, we love to learn, and we love to make learning fun, which is why we are always looking at workshops and katas to run during personal development time. We also find that these can be used as team building and cross team exercises. An example we ran recently was a Risk Storming session.
An introduction to risk storming
For those that have not experienced Risk Storming, it is an exercise based around the Ministry of Testing’s TestSphere card deck. The object is to take a ‘product’ (examples given on the website include the Death Star and Iron Man’s suit), imagine it is at its planning stage and identify the risks that it may have, and from there, work out how to mitigate or, even better, remove those risks.
Firstly, using the blue cards from within the TestSphere deck, the team identifies six “Quality Aspects” that they believe may be important. For example, one of the potential “Quality Aspects” is “Safe-Guard”, subtitled “Security Aspect: What’s keeping the bad guys out?”
Once the Quality Aspects have been identified, the team take post-its and pens and try to think of specific examples of the Quality Aspects might be problems. For example, if you were looking at the Death Star, you might see having an exhaust port that you can fire a proton torpedo down so that it causes a chain reaction as a risk. With Iron Man’s suit, you might see unauthorised users being able to give instructions to Jarvis as being a potential risk.
Finally, the rest of the cards are used to look for techniques, patterns, heuristics and feelings that might be relevant in testing these risks. An important thing to remember is that there are no ‘right and wrong’ answers - it’s an exercise to promote conversation and discussion, and get people thinking about risk when embarking on a new project.
Our first Risk Storming session
to come through the door is useful.
For our session, we decided that a self service checkout would be a good thing to work on. It was something universal, although it’s a fair assumption that most people, especially working in a software house, will know Iron Man and the Death Star. The session was open to anyone from any department.
The first thing we found was that picking just six Quality Aspects was difficult. It felt like just about every card we discussed could be relevant in some way. Being forced into limiting it to six Quality Aspects was a good way of forcing discussion, as people had different reasons to want to prioritise in the order they did. In the end, the Quality Aspects chosen were User Friendliness, Functionality, Complexity, Concurrency, Safeguard and Accessibility.
The board then became a chaos of post-its as the team broke down the Quality Aspects. Personal experience came to the fore here, as people related their own trials and tribulations of using self service checkouts, for example not being able to find loose vegetable or bakery items, which seemed to be something we’d all experienced. This was seen as a good example of an issue with Friendliness (although it could have gone under Functionality or Complexity). Various elements of Accessibility were discussed, like having decently sized touch areas on the screen, as well as legible fonts, and under Concurrency we placed the possibility of swiping items too quickly and the scales believing that the bags were too heavy as a result.
The team then proceeded to place techniques, patterns, heuristics and feelings against the most relevant Quality Aspects. For instance, the ‘Too Many’ Heuristic was applied to the Concurrency Quality Aspect. The “Business Scenarios” card was allocated to Functionality - is the device actually going to be benefiting the business, or is it a solution created for a problem that doesn’t exist, as was Standards and Regulations - were children buying alcohol and solvents?
Conclusion
A lively and enjoyable exercise, the Risk Storming session helped people to consider risk in a way that they might not have considered before. For those outside of the QA department, I believe it provided some appreciation of the way we view things, and for those within it, it was a chance to step back and examine our own ways of thinking, as well as adding a few more tools to the QA toolbox that we carry in our heads. There has been interest from across the company, and more sessions have been scheduled with people from across the company. As well as getting people to consider risk, it’s also a good way to make people aware of, and discuss, quality in the wider sense.
Chris Dabnor
Read more by Chris Dabnor
