Defect Priority v Severity: Debate No. 763

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


4 thoughts on “Defect Priority v Severity: Debate No. 763

  1. Your definition is the same one I use. In my experience, in some companies, many people do not care about a separate priority value for most of the project, as severity is good enough. Sometimes in the same project before release the same people then wish priority to be specified. Which is all okay. On an Agile project, do we even need to document the severity and priority at all? The values most certainly may be thought of, but do they need writing down? Maybe yes, maybe no.

  2. Isn’t it as simple as ‘severity = objective assessment of defect impact’ and ‘priority = subjective assessment of defect impact’ ?

  3. Along those same lines…

    Ode’ to a Bug
    In the beginning there were ‘bugs’, they were not considered to be a good thing. But they were real and present, and in mass numbers at times.
    These bugs were ‘defects’ in the code or design of the system, and as such caused an ‘issue’ for the people both using the system and building it.
    Thus if a bug was found an issue was raised by the users and they would point out the defect to the developers.
    The developers would fix the defect so that is would no longer be an issue and as a result remove the bug from the system.
    But in some instances the defect was found to actually be an ‘anomaly’ caused by an ‘inadequacy’ in the original specification of the system.
    This caused the system to naturally contain a defect that would eventually become an issue because it would just bug users because it was present.

    Now because the inadequacy propagated the anomaly which led to the defect and caused an issue the end-users would just have to live with the bug.
    Alas, the end-users complained and then management got involved. To smooth things over they proclaimed that the bug is not a defect and there was no longer an issue.
    Instead they stated that the issue caused by the anomaly due to the inadequacy was actually a ‘functionally unreproducible business application response’, or FUBAR.
    This FUBAR in turn would just make the ‘system not available for use’, or SNAFU.
    This SNAFU was the real culprit behind the FUBAR and explained the inadequacy which removed the anomaly that raised the issue that was depicted by the defect which just bugged users.

    This eventually led the users to believe that no matter what, a ‘bug’ will eventually lead to a FUBAR that causes a SNAFU.

We're here to help

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

You are commenting using your 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