A dear friend of mine (let’s call her Cheryl – because that’s her name!), sent me a message on LinkedIn today. Here’s the central question – “If you avoid looking at IEEE or ISTQB, in your opinion, what do you think is the right description of Defect Severity v Defect Priority? Does it vary based on agile v waterfall worlds?”
It is my experience that we have been debating the concepts of Defect Priority and Severity for most of my 25+ years in software testing and I have been asked hundreds (probably thousands) of times, to define/explain/clarify etc. these terms. On top of this, as Cheryl points out, there are “standards” that define these terms also. So, in the expectation that this could be a protracted debate (which is something I’m quite comfortable with, by the way) here is what I said to Cheryl,plus my broader thoughts on the subject….
“Hi Cheryl, great to hear from you – Happy new Year 🙂
My views on this question haven’t really changed over the years and I know plenty disagree but (from a triage perspective) Defect Severity is the impact on the business and/or technology capability, while Defect Priority is the impact on getting the solution out there. For me this means that in a context where external customers are the primary users, Severity is always more important, because you can’t always (perhaps even rarely) contain the impact of a high severity defect.
It’s an interesting point you raise regarding agile v waterfall – and one I hadn’t really considered much before. My initial view is that the context within which you are working is key. I would probably say that momentum is more important in most agile contexts, but if you were working on mission critical stuff, I’d be back on Severity. I think it’s a great question regarding agile v waterfall as there are far more non-testing specific complications in play.”
So, there’s the initial discussion and here are my broader thoughts (and the context within which they live)…..
I have spent the majority of my software testing career driven by and focused on customer-centric outcomes. By this I mean that if the customer (or user, more generically) can’t use the software effectively and efficiently there’s not a lot of point in producing it in the first place. I have always been more driven by outcomes than journeys and for me the Priority of something like a defect is part of a journey, while the Severity of a defect (while possibly waxing and waning) will generally remain long after the software is released (unless there is a significant business shift). Putting it slightly more bluntly, shit will always be shit.
As I said in my response to Cheryl, the context within which we discuss and agree these things is key and there are so many contexts within which we all work and more broadly exist. Therefore, my strategic and operational solutions to introducing Defect Severity and Priority guidelines over the years have been varied; however, the bottom line for me is that we identify the impact and root cause of a defect as quickly as possible (triage) and then get it fixed within the most appropriate timeframe that our business allows. And this is where the question of agile and waterfall seeps in. The waterfall approach will more often than not mean that there is far more time for reflection and planning and I have seen the Priority and severity of defects change significantly as the various test cycles unfold. This is less likely in a more agile environment.
I think I’ve provided enough insight into my own ideas here without getting too specific or contextual. So, what is the current consensus out there. I’m eager to hear from anyone, whether they agree or disagree or want to build on or tear down my thoughts.
Dateline: Sunningdale, Thursday January 5, 2017
PS Happy New Year everyone