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.
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:-
- the impact if things go wrong – e.g. Coronavirus vaccine testing
- the impact if things go right – e.g. the government programme to use drones to fly medical equipment to the Isle of Wight was brought forward at the start of the Coronavirus pandemic in order to “accelerate the pace of development”
- competition – sometimes being the first to market, even with bugs, is better than releasing too late to the party
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?