RiskStorming Workshop Experience

By Uros Stanisic

A considerable part of a software tester’s job includes creating a test strategy. The process of defining a test strategy often sounds intimidating and not straightforward when explained to less experienced colleagues.

Some time ago, an awesome article was published proposing RiskStorming with TestSphere cards as a way to define a test strategy. It sounded fun and was an opportunity for the team to run a workshop. Usually, RiskStorming sessions are run together with developers and business people to identify the most important concepts that will help with creating the test strategy. But for our first run, we decided that the test team should try it out during one of our regular, weekly knowledge sharing sessions.

Introduction To RiskStorming

In the beginning, there was a short intro and the purpose was to get everyone on the same page, acquainted with the cards, and to explain all the rules and three phases of the RiskStorming. The team selected the system under test: a well known messaging app. The reason we’ve picked a messaging app was that the team in the room used it and we’ve felt that, for the first exercise, we should use something which was widely known to everybody involved.

Phase 1: Narrowing Down The Quality Aspects

The main goal of this phase is to select the six most important quality aspects out of the 20 quality aspect cards available. There was an expectation that since we’re working with a familiar app, it would be easy to pick six quality aspects. That expectation was wrong. People started going through the blue quality aspect cards and, in the first turn, we had selected 15 quality aspects. It was repeated several times that we needed to narrow it down to six, but people were really reluctant to remove some of the aspects because they felt they were necessary. There was even a proposal to remove a functionality card in order to make room for something else because it would be tested anyway.

In order to speed things up, we have agreed on two things:

Aspects not chosen were not disregarded: The team selected six of the 15 quality aspects which were then given top priority for this workshop.
Context shifts: for this exercise, these six were important. We didn’t know what quality aspects would be valid in a month. It could be something completely different, and that would be OK.

Making these agreements finally lead our team to the six quality aspects they considered most relevant.

Phase 2: Adding Risks

Once our team had narrowed down to six quality aspects, things got interesting. The team had a slow start adding risks. We were gazing at the quality aspect cards, but rarely added any risk related to them. We came to the realization, during this process, how much our team didn’t know about the product, even though everyone was familiar with it and had used it at some point. Our team had so many questions and unknowns that we started questioning decisions about the quality aspects they had chosen.

Risks started pouring to the table once we agreed that we would not change the initial choices. Everyone wanted to add a post-it with a risk written down. And testers being testers, they started arguing whether we should use the same post-it colors for specific types of risks. Fortunately, this idea was abandoned quickly as time was running out for this particular part of the exercise.

RiskStorming board with risks added

Phase 3: Mitigating Risks

This was probably the most vibrant part of the workshop. People were shuffling cards like crazy and everyone was invested in getting the risks mitigated in the right way. That was not easy. Multiple cards exchanged many hands attempting to do this properly. In the end, this phase lasted a bit longer than recommended, but it was important that we were satisfied with the end result.

Discussing Risks And Respective Mitigation Measures

After risk mitigation was resolved, our team spontaneously started with the most interesting, and lengthiest, part of the workshop. As soon as we completed the big picture, people have started discussing reasons why some risks had been added and why others hadn’t. Similarly, the discussion went to mitigation measures for those risks and other questions started to emerge like:

Is this enough?
Should we add/remove some measures?
Can one measure cover more than one risk? Is it allowed by RiskStorming rules?
Should we invent some new cards if a specific measure cannot be found in the deck?

Final RiskStorming board with all risks and mitigation measures

After the lengthy discussion, our team agreed that it would be best to stop there and decided on the “final board”; selected six quality aspects, the risks associated with them, and the mitigation measures that represented the test strategy in the current context. As with any real project, our team would need to pay attention to how those shift over time so that we could adjust the strategy accordingly.

Here are some additional ideas our team agreed to apply to future sessions:

If one mitigation measure covers multiple risks, rethink both the measure and risks. Maybe those risks could be bundled together or the measure could be replaced with other, multiple measures.
If our team identified a mitigation measure for which there was no appropriate TestSphere card, then we would create our own card.

Some Afterthoughts

The workshop was probably not a typical one, or at least it did not follow some of the intentions of the authors:

The team was around 15 people.
It lasted longer than recommended. The actual time was very close to three hours. This was probably related to the team size.
Our team picked the product we all used and knew well. However, since we’ve vaguely discussed the scope and scale at the beginning, we struggled with some quality aspects as well as risks.

During the workshop, all of us have had a great time! Our team enjoyed an inclusive workshop where everyone had a chance to speak up. It was a great opportunity for everyone to learn together, which is not easy to accomplish.

A few ideas popped up regarding TestSphere cards during the workshop:

Make them magnetic, so that our team can stick them to the whiteboard (or fridge)
Make individual images of them, so that our team could use them in a mind mapping tool

TestSphere creators have been contacted about these suggestions and hope to hear some feedback from them.

Future Plans

Our team definitely plans to organize more RiskStorming workshops with products they are working on in the future. To have the team finish in the recommended time, it was decided that smaller sized teams would be organized for the workshops.

We would recommend running RiskStorming workshops for the following reasons:

It is a different and fun way to create a test strategy.
It allows less experienced team members to get acquainted with new terms and their context.
It is inclusive and a great team exercise.

Why not have a go at running your own RiskStorming workshop at your company? You can find all the information you need on Ministry of Testing’s site and share your experience on The Club.

References

Author Bio

Uros Stanisic is a very passionate software tester with over ten years of experience on international projects in various business domains. He is one of the co-founders of Test’RS Club, a community of professional software testers and first testing community in Serbia. He regularly shares his experience gathered in software testing both at local and international events. Currently, he works as a head of testing in Execom.

When time permits, Uros enjoys indulging in his foodie nature and an occasional glass of craft beer. He can be found on Twitter @uros_stanisic.