Let's talk about figuring out risks!

(Gem) #1

Okay, so, favourite methods, stories, experiments (failed and successful) on gathering risks from various parts of a team?

Background: I’m overhauling our automation, and want to figure out not only what I think the risks are for the product but what the devs and the product owner think are the risks. This will be helpful for automation and everythng else - I know where to put my efforts best when I know what the risks are.

I’ve suggested a risk storming session, but while I wait to see if that’s going to happen, I thought I’d tap into this resource as well :smiley:

At the moment the product owner is thinking mostly in terms of the user path and what bits of that is critical, but I want to make sure we’re covering everything - performance if that’s a priority or stability or whatever.

There’s also a method around asking what headlines about the prduct would be that I’ve heard but my google skills are failing me in finding that one.

Let’s share tips :smiley:

(Jasmin) #2

Sounds like you’re talking about Elisabeth Hendrickson’s Nightmare Headline game. I’ve found it to be useful in getting people involved in brainstorming risk since it makes it a little bit fun to think of it in terms of disaster headlines.

(Gem) #3

That’s the one!

I was wondering if I could expand it to: what would appear on the front page (the world is over), what would be on page 4 (annoying and doesn’t look good but not the end of the world), what would be in a letter to the editor (we might look at that if we run out of work to do)

(Anders) #4

It sounds like you’re looking at product risks, i.e. risks concerning what happens when the system is in use. That’s a very good start, I think. I also think the “user path” is a great place to start as that’s where the value/usefulness of the system will be evident. And product risks are threats to the value of the system.

The expeirence I’d like to share comes from a MoT workshop I facilitated in January where we brain stormed about product risks (will the product do what it’s inteded to do), project risks (over budget/delay/not meeting functionaly), and a class of complex risks that I termed systemic risks in the workshop.

Being systemic, these are indirect in nature, e.g. something bad happening despite being on time, on budget and delivering what’s wanted.

That turned out to be an interesting exercise as we looked at the promises made for the wonderful things this system would deliver (happier users, safety, better quality, stuff like that) and imagined how those promises could possibly be jeopardized when the system was implemented.

Technically, what we came up with were hazards, but I think we talked about them as possible negative outcomes, and the the end result was an interesting set of test strategies.

As for automation, I suggest you take a look at the STPA analysis technique that I am working on describing how it woks in testing. It is an analysis technique coming from systems safety research and it gives us a way to analyze a system and figure out hazards and tests on a component level instead of user path. This will work better in automation, where we always strive to reduce granularity of tests. Take a look here and feel free to ask questions.

Best,
Anders