Risk Storming
As you may have noticed in our QualityHeroes podcast, we have introduced a bi-weekly “Let’s Test Sessions” in our testing team. During the sessions the team members interested in expanding and sharing their knowledge present well-known as well as less well-known testing methods and try them out in practice.
Recently we tried out Risk Storming.
The goal
With Risk Storming, you can identify and minimize product risks collaboratively and across teams. It is best if the entire product team is involved and thus contributes “hands-on” to looking at the product and its risks from different perspectives.
What you need is:
- a game plan
- a TestSphere card set
- a pen and some post-its
- One-Pager Test Strategy form
With the help of the TestSphere cards and the test strategy one-pager test strategy recommended by us, it becomes clear to everyone involved what can be tested, how and when. The card set also contains cards on the topics of heuristics and technology, with the help of which new (test) ideas are constantly being created. The whole thing is genuinely exciting even for those of our colleagues with more years of experience under their belt.
What did we test and how:
A made-up web application for the sale of used goods, which is available in German and English, served as a test object. We changed the approach a bit and implemented a Lean Coffee version of Risk Storming, simply to limit the session to a maximum of one hour and to be able to play online.
For our online session we needed the following:
- Risk Storming Board online (we used Mural)
- A selection of product risk card
- Online meeting tool
We agreed on the product risks of security, functionality and data and checked our made-up application for these three aspects. Many ideas quickly came up as well as questions and risk aspects which should be taken into consideration already in the development phase. They indicate what needs to be tested and where further risks and hurdles lie.
We had many questions concerning usability. For example: should the images of an item for sale be controlled as well? Which image formats and maximum upload file size limits should the web application support? Can any type of item be sold or should there be some legal restrictions, for example regarding the 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?
In the course of the session, more and more questions came up and showed that supposedly simple topics are often much larger and can also be dependent on other risk aspects.
Conclusion:
Within just one hour, we came up with many ideas for tests. We identified both product and project risks that we could clearly communicate to all stakeholders in a real project. With the one-pager for the test strategy we created, the project would quickly have a “lightweight” documentation containing everything important.
If you found our summary useful, stay tuned! Soon we will be offering Risk Storming workshops which you can apply to your project.
Learn more about Risk Storming in the QualityHeroes podcast (in German): https://qualityminds.com/de/qualityheroes-podcast-folge-20-was-ist-ein-risk-storming-workshop-und-wie-kann-er-einem-projektteam-helfen-2/
Do you have any questions? Contact us at testing@qualityminds.de
Our testing team portfolio: https://qualityminds.com/services/core-qa-services/functional-testing/
0 Comments