How we run RiskStorming:
The RiskStorming session format is a wonderful way of generating a visible Test Strategy as a team that automatically focuses your plan to answer the question:
How do we test (3) the risks that impact (2)
the aspects of our Product that matters? (1)
Essentially, the format makes you go through 3 phases.
- Which Quality Aspects matter most for your product?
- Which risks endanger those Quality Aspects?
- How do we test to make sure those risks don’t happen?
RiskStorming explanation video
An example of one Quality Aspect and the three phases
Imagine we’re testing the new booking feature of our preferred railway application.
While thinking about the important Quality Aspects, we select Concurrency to be an important aspect to test for, but might disregard Security for now. That’s a difficult decision to make, but it’s one made by the team.
Phase 1 – 15 min: The team starts RiskStorming by making hard decisions about what’s important to the application and discuss this topic thoroughly. TestSphere offers 20 different Quality Aspects, such as Accessibility, Clarity, Resource Management, User Friendliness & Complexity, yet RiskStorming only lets you select 6 of them. These 6 cards will decide the path you’ll take in the next phases and should be chosen very carefully.
In our example, you could consider the following 6: Concurrency, Usability, Performance, Stability, Security & Data.
Phase 2 – 20 min: For each of the aspects selected in the first phase, we now get brainstorming about risks. In our example, one of the bigger risks for Concurrency is two or more people booking the same seat at exactly the same time. This conflict could result in problems for the firm and possible money loss as well as reputation.
We want testers to focus on these two things: Loss in Business Value and Negative Impact on the company. That’s what we’re being paid for, right?
Phase 3 – 20 min: We take the Heuristics, Techniques and Patterns cards of the TestSphere deck and use these to brainstorm test ideas on how we’ll be testing to protect us from those risks.
To check for Concurrency, we might want to do Log digging, (ab)use Performance Testing tools, try Pair Testing and/or use Force patterns to ramp up similar booking calls for more people at the same time. Another tactic could be to Starve resources (limiting number of possible seats) to make our checking easier, should there be a randomizing algorithm,…
Repeating this for every Quality Aspect & Risk, you get a well formulated tactic that is not only understood by the whole team, but is actionable by not just the Testers.
Optional: Phase 4 – 20 min: Distill everything into a one-page-test-plan to formalise all the discussion points and decisions you have taken as a team.
A one page test plan template:
1. You will work as a team to discuss and describe a Test Strategy;
2. You will work out a proposal to convince your manager which forces you to focus on business value and risk;
3. You will use TestSphere as a tool to uncover unknown-unknowns and strengthen your strategy.