Risk is… in the eye of the beholder

Millions and millions of years ago, back when I was studying for my Law degree, I was surprised to learn that far from the truth being objective and fixed, it was a malleable thing.

Mooting societies, where aspiring lawyers could pick a side to debate about a particular case, or topic, were popular. And they were popular because either side, with the right amount of well constructed arguments and material, could win.

definition of risk from dictionary.com

Fast forward to my current life as a software tester, and this subjective fluidity also applies to risk. There are many different ways to prioritise bugs, issues or features – including whether to raise them at all if you think they won’t get fixed.

The one thing that seems to consistently hold true is:- most people assume everyone thinks the same about risk as they do.

The confirmation bias is strong in this one.

I’ve often been shocked, even when an agreed categorisation table is in place for both priority and severity, triaging bugs that I would deem super critical, only for the Product Owner or wider team to prioritise something I would consider far more trivial instead – sometimes I understand why, other times the rationale seems flawed. As a tester, I see risk everywhere, which can be a good thing, but needs to be kept in check. Sometimes a pragmatic way forward needs to be accepted by everyone, where not all bugs can be fixed, and we “fail-forward”. UPDATE: An interesting approach that I’d like to investigate more on bug raising was outlined at a recent Lean Coffee morning I attended. Stuart Day, Principal QA and Agile Coach at Dunelm, advocates not raising bugs at all (or hardly ever) – as most bugs take more time to create, triage, prioritise and fix than they do just to have a chat with the developer and get them sorted there and then (or even fix them yourself if you can). Whilst I’ve informally done this from time to time, I’ve never seen it be openly advocated from a senior manager in this way, and it definitely peaked my interest. I guess you can be the judge of whether that approach is more or less risky.

Of course, the risk appetite is greater or weaker depending on other factors too, such as:-

A great example of how we all asses risk differently is with Coronavirus (I realise this post is weirdly Covid-19 heavy, but bear with me!). I have lots of conversations with friends and family who consider “bending” the rules absolutely fine, whilst others stick rigidly to the government guidelines. Everyone feels their approach to risk is the right one. Often people, are quick to criticise others for exposing themselves to “unnecessary” risk which they themselves justify taking “I just don’t understand how these big crowds are going out and mixing together. I had a party in my back garden yesterday, but that was OK because it was just my neighbours and some family”. etc. etc. Risk is in the eye of the beholder.

I think in general the ubiquity of software means that most people have a reasonably high risk appetite when it comes to, say, an app, or even an early release of any software product. They accept that if they are “early adopters” or “beta testers” the development team are still working through issues. The important thing IMHO is to find the time and the space to fix the “cosmetic” or “usability” issues, often found in user testing or by testers themselves, which negatively impact their experience of the software. Workarounds shouldn’t have to be used forever, and companies who continue to treat their users in this second rate way may pay a heavy price. Perhaps this is where Stuart Day’s approach to fast bug fixing would pay off?

Thank you to the Bloggers Club at the Ministry of Testing for inspiring me to write this. You are awesome.

2 thoughts on “Risk is… in the eye of the beholder

  1. One risk people tend to overlook in corporate situations (until it impacts them) is ‘risk to self’ (usually the risk to your job: most IT-related roles do not involve risk to life and limb most of the time). The model question here is: “If this bug goes unfixed and gets out into the world, will I be at risk of getting sacked for it?”

    This can elevate some comparatively minor bugs – typos, for instance – to the highest priority, depending on how visible they are and much they would offend someone very important. I’ve worked for CEOs in the past who would take a very dim view of trivial bugs that reflected badly on them or the organisation, no matter how minor they might appear in absolute terms.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: