Testing is a craft, but it is also and for many foremost a job. A job you do day in day out, evolving with all the rituals every employee develops over time. These rituals, together with all sorts of other external factors (deadlines, pressure, etc.) often means that we don’t have a test strategy or that we are no longer reconsidering the strategies we set out from the start. Having the right strategy in testing is important to stay as efficient and effective as you can be.
This workshop wants to reignite your strategic fire by placing you in small groups with your fellow testers. Together you will devise a strategy for a real life product which includes methods, tools and planning. However, just like in reality the context will change, and our strategy must change accordingly to aptly react to that change. The workshop will use the TestSphere cards as a support to spark discussions and for bolstering your strategy.
1. You will work as a team to discuss and describe a strategy to tackle a real life case and problem;
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.
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
Printable boards in different formats:
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.
Phase 2 – 20 min: For the aspects selected in the first phase, we now get brainstorming about risks. In our example, one of the bigger risks 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, use Performance Testing tools, try Pair Testing, use Force patterns to ramp up similar booking calls for more people or Starve resources to make our checking easier,…
All these cards give you new ideas to test off those risks.
Going through the motions of the three phases for six different quality aspects will generate a rough test strategy that was decided upon by the whole team.
Distilling this in a one page test plan is a valuable next step.
A one page test plan template: