In our testing Community of Practice (CoP), we are always experimenting with new testing methods. Recently, we tried out Risk Storming as a collaborative approach to identifying and minimizing product risks across teams.
The goal of Risk Storming is to involve the entire product team in looking at the product and its risks from different perspectives. To begin, we needed a game plan, a TestSphere card set, a pen, some post-its, and a One-Pager Test Strategy form. Using the TestSphere cards and the recommended one-pager test strategy, everyone involved gained a clear understanding of what could be tested, how, and when. The card set also contained heuristics and technology cards that generated new (test) ideas. Even colleagues with more experience found the process exciting.
We tested a made-up web application for the sale of used goods, which was available in German and English. We used a Lean Coffee version of Risk Storming to limit the session to a maximum of one hour and to play online. For the online session, we needed a Risk Storming Board online (we used Mural), a selection of product risk cards, and an online meeting tool. In an on-site workshop, we would have used post-its, the full deck of cards, and a one-pager for testing strategy.
We focused on product risks related to security, functionality, and data and checked our application for these three aspects. Many ideas quickly came up, along with questions and risk aspects that needed to be considered in the development phase. These questions indicated what needed to be tested and where further risks and hurdles lay.
During the session, we had many questions concerning usability. For example, should we control the images of an item for sale? Which image formats and maximum upload file size limits should the web application support? Are there any legal restrictions on what types of items can be sold, such as protection of minors? After a successful upload, would someone check the articles and images offered on the platform? Is there a difference between the desktop application and a mobile application? Are the functionalities on the mobile app fast enough?
The session generated more and more questions, indicating that seemingly simple topics are often much larger and can be dependent on other risk aspects. In just one hour, we came up with many ideas for tests and identified both product and project risks that we could communicate clearly to all stakeholders in a real project. With the one-pager for the test strategy, we created a “lightweight” documentation containing everything important.