RiskStorming: How to reinvent your test strategy

“What’s your current test strategy?” Managers used to spring that question on me as they passed by my desk during fly-by check-ups on the status of their projects.

It used to take me by surprise. Why were we testing the things we were testing and not others? I knew there was an inherent strategy behind our work, but I couldn’t explain it or defend it when challenged. Because I didn't have a coherent answer, I wasn’t taken as seriously as I should have been, and my explanations didn't have the impact I wanted.

I’ve felt this pain during many projects, I've seen it happen to other testers, and I feel it when reading blog posts. I needed to get better at this, and our testing team needed testing to be better understood, so we invented RiskStorming.

Here's how RiskStorming can reshape your testing strategy.

World Quality Report 2018-19: The State of QA and Testing

RiskStorming with TestSphere

The RiskStorming session I'll be running during the Romanian Testing Conference describes a way to generate a visible test strategy that automatically focuses your plan to answer the question: How do you test the risks that affect the aspects of your product that matter?

RiskStorming takes you through three phases to get the answers.

  • Which quality aspects matter most for your product?
  • Which risks endanger those quality aspects?
  • How can you test to make sure those risks don’t happen?

The technique uses a TestSphere card deck from Ministry of Testing and a free-to-print game board board you use to visualize risks. It makes the process fun and collaborative.

The TestSphere card game is designed to get your team thinking and talking about testing. Each pack includes 100 cards that fall into five dimensions:

  • Heuristics: Possible ways of tackling a problem.
  • Techniques: Clever activities used in testing to find possible problems.
  • Feelings: Every feeling triggered by your testing should be handled as a fact.
  • Quality aspects: Aspects of your application that may be of interest.
  • Patterns: Patterns in your testing, and patterns that work against you in testing, such as biases.

You get 20 cards for each dimensions, each of which contains:

  • A testing concept.
  • A slogan that explains the concept.
  • Three examples that put the concept in a different light.

In all, you'll have 300 examples to discuss, learn from, and draw upon for ideas.

RiskStorming uses TestSphere to focus discussions on what’s important and how to deal with the problems that might come your way.

A real-world RiskStorming example

Imagine that you're testing the new booking feature in a preferred railway application.

While thinking about the important quality aspects, you select concurrency as an important aspect to test, but disregard security for now.  Here's how you get started:

Phase 1 - 15 minutes

Your team starts RiskStorming by deciding what’s important to the application and discussing the subject thoroughly. TestSphere offers 20 different quality aspects, such as accessibility, clarity, resource management, user friendliness, and complexity, but in RiskStorming you can only choose six. These cards will determine the path you take next, so chose carefully.

Phase 2 - 20 minutes

Brainstorm about the risks for the aspects you selected in the first round. One big risk in this case is that two or more people will book the same seat at the same time. This could create problems, result in lost revenue, and damage the business' reputation.

As a tester, this is what you want to focus on: Loss of business value and negative impact on the company. 

Phase 3 - 20 minutes

Use the heuristics, techniques and patterns cards in the TestSphere deck to brainstorm ideas on how to use testing to protect the business from the risks just identified.

To check for concurrency, consider doing 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 checking easier. 

Use the cards as a source of ideas for testing those risks.

Collaborate and learn

Through RiskStorming, you'll work as a team to build a map of what your testing will look like. Then you'll learn from each other as you collaborate.

During my full-day tutorial on RiskStorming, I use this format to guide attendees' test planning, test sessions and learning sessions to achieve the goals generated within their teams. But you can go deeper, and you can use it to kickstart your own testing journey.

Time to get in the game

Ready to play RiskStorming with TestSphere? Here's how it works.

https://lh6.googleusercontent.com/R44aw_kwwDwatLr_JQaW88uUDp09NFZSmXN_SSx-kokRJZgoBheAIZU4by0tU1V2IMScdAs_58CXyfxAPQP7ywCA-MEcjPUIGB8yA1zEqqq-f0mo55KKkkNL9TuPSsQRu5jApcIoRiskStorming in action using the TestSphere card dek and playing surface.

Notice the three circles in the picture above, which shows TestSphere in action. The innermost blue square includes six blue cards, which represent the quality aspects selected by the team.

The beige square includes the sticky tags that cluster around the blue cards. Each represent a risk the team identified.

The third, outer square includes the purple, pink, orange and green cards that represent the techniques, patterns, heuristics and feelings the team wants to use, think about, and be mindful of when they test the risks identified in the second phase. This square guides you by asking your team to focus testing on what matters: the potential impact on business value and reputation. 

Want to want to know about how to run your own RiskStorming? Read Marcel Gehlen's blog post on mapping risks with TestSphere. For more on TestSphere itself, read about it on the Ministry of Testing website.

And for hands-on advice, don't miss my all-day session at the Romanian Testing Conference, where I'll offer plenty of detail on how to reinvent your test strategy using RiskStorming. The conference begins on May 9. Can't wait? Post your questions and comments below and I'll do my best to answer them.

Topics: Dev & Test