Over the past year or so, I’ve been actively using my deck of TestSphere cards, mainly as a way of introducing people to the mindset of testing. Recently, however my good colleague Stu Crocker introduced me to RiskStorming – a board game which used TestSphere cards to help create a risk-based project test strategy.
So, with the planet gripped by World Cup fever and the Internet nearing breaking point under the load of “It’s coming home” memes, what better way to spend a rare football free day, than meeting up with a few like minded software testers and trying out the new game.
We started by picking a System Under Test to discuss. With it being the World Cup we opted for VAR – the new Video Assistant Referee system which has been introduced to assist referees when making critical in-game decisions, with the help of video replays.
We then began to identify the six most relevant blue cards (Quality Aspects) from the TestSphere deck. As we discussed these, however, it soon became apparent that we didn’t have a common understanding of exactly what we meant by the term VAR. This prompted us to decide upon a common definition, and to clarify the scope of the system. After a short discussion we ended up with the following list:
- Audio communication between the pitch referee and the assistant referee
- Video feeds from the existing TV footage
- Recording of the live TV feeds
- Interface for switching between feeds and pausing, rewinding, fast forwarding the footage
From here we were able to identify the most relevant quality aspects, such as stability, performance, install-ability, user-friendliness and so on.
Once we had agreed, we then discussed each of the quality aspect cards in turn and began identifying some potential risks. This prompted some lively debate and we were able to cover a wide range of risks in a short time. With our creative testing juices in full flow, we were able to identify risks not only to the operators of the system (the referee and assistant) but also the wider risks to the players and fans, the commercial risks to the teams and sponsors and the potential risks to the reputation of FIFA and the Russian Football Union.
Now came the final phase of the game where we were to identify some appropriate patterns, techniques and heuristics that could be used to mitigate the risks. We began by selecting a couple of cards each at random from remainder of the TestSphere deck. Then we took turns to read out our cards and attempt to apply them to one of the risks.
For me this was where the game began to lose its focus. Personally I find some of the descriptions on the cards to be unhelpful and the examples often have little relation to the title, or can be too prescriptive. Also it became apparent that a lack of context about the project and the team meant that we had to make several assumptions.
Nevertheless we were still able to have a productive discussions and offer suitable mitigation to some, if not all of the risks.
In conclusion, I feel that the RiskStorming approach is great for identifying potential risks within a project and the game provides a simple structure to follow. For those looking to try the game I would suggest reading the heading and the brief description on the cards and not getting too hung up on the examples listed towards the bottom.
I am yet to see how RiskStorming can be used to truly identify relevant mitigation actions for risks, or how these could be used to create a test strategy for a project. However I have begun looking for a real project at work that I can apply it to and I’m hopeful that the process will get better with practice.
Overall I think World Cup Risk Storming was a great success. Now bring on the quarter finals, COME ON ENGLAND! #itscominghome