Severity and Priority

Severity is about the risk a bug poses if it gets out into the wild.

Software risk can be characterized as: The potential for some fault, failure or other unintended happening in the implemented system to cause harm or loss to one or more persons or organizations.

We assess the risk of a bug by asking questions about impact and probability. How much harm could this bug cause to something the customer cares about, such as human safety or the bottom line? How likely is this bug to manifest (noticeable) and how likely is that harm to occur if it does?

If a bug could cause significant harm but only manifests under very unlikely circumstances, then we might decide it’s less severe than a bug that could cause less harm but manifests frequently. Or not, depending on the context.

Priority is related to Business aspect:

1. Must fix as soon as possible.  Bug is blocking further progress in this area.
2. Should fix soon, before product release.
3. 3. Fix if time; somewhat trivial. May be postponed

 Severity is related to Technical aspects:

1. Bug causes system crash or data loss.
2. Bug causes major functionality or other severe problems; product crashes in obscure cases.
3. Bug causes minor functionality problems, may affect "fit and finish".
4. Bug contains typos, unclear wording or error messages in low visibility fields.

Most organizations have standard criteria for classifying bug severity, such as:

Severity 1 – Catastrophic bug or showstopper. Causes system crash, data corruption, irreparable harm, etc.

Severity 2 – Critical bug in important function. No reasonable workaround.

Severity 3 – Major bugs but has viable workaround.

Severity 4 – Minor bug with trivial impact.

Typically, Severity 1 and 2 bugs must be fixed before release, where 3’s and 4’s might not be, depending on how many we have and on plans for their subsequent disposition.

Priority, on the other hand, is about the order in which bugs need to be fixed. Often, priority and severity run hand-in-hand: a bug is both high severity and high priority to fix. But that’s not always true. Occasionally in testing we’d like to have lower-severity bugs fixed so we can explore an area more thoroughly and see if they’re masking something else. Particularly on large projects, we can also find that we have a larger number of high severity bugs open than the programmers can readily fix. In this case, we need to specify the order for fixes based on where we plan to test next. To some extent also, ease of programming kicks in. A programmer working on high severity bugs in a particular module may choose to fix the low severity bugs in the same session.

At least theoretically, bug severity doesn’t change. The potential for business or technical impacts stays pretty much the same throughout the development project. (The passage of time can affect risk, but that’s a subject for another post.)

Priorities for fixing bugs do change depending on where we are in the project. At first, it’s testing priorities that matter most. But the closer we get to release, the more important the customer’s priorities become, to the point where they take over entirely.

And that brings us to an essential question about both severity and priority. Who gets to decide?

Ultimately, it’s the customer’s prerogative to decide both severity and priority (using “customer” as the stand-in here for “key decision-makers”). We—testers, project managers, and programmers alike—can make educated guesses about business risk and even about business tolerance for risk, but we can’t really know and we certainly can’t decide for the customer. Similarly, we can’t decide bug fix order for the customer, who frequently has different priorities from ours.

That’s not to say we abdicate responsibility. It’s a tester’s job to try and represent the customer’s point of view when they are absent. It’s also our job to help customers make those decisions. We do that by attempting to understand the true significance of a bug and communicating our understanding. We also ask questions to help our customers assess relative risk. (As anyone who has ever supported UAT knows, customers frequently assume everything is equally high risk until we ask those questions.)

It’s good to engage with customers and ask those questions early, ideally as we go through the development project. (Agile projects have it easy in this regard.) Early engagement is especially important for assigning severity.

But until we reach the point in the project of determining bug fix priorities for release, it’s only practical for the entire development team to set priorities according to what’s needed to move the project forward. Most often that means the testers’ needs: the bug fix priorities for testing.

Of course, there are other factors affecting priority during a development project, including the relative risk and cost of fixing a bug. But generally speaking, it makes sense for testers to drive priority until we switch over to the customer’s priorities for release.

High Severity bugs examples

Severity: seriousness of the defect with respect to functionality

Most applications generally have a "Help" menu. "About" is a menu item under "Help" menu which provides details about the application, its version etc. So, if clicking on "About" menu item in an application crashes the application, it can be considered a bug with high severity and low priority. High severity because the moment this link is clicked, application crashes and users can't work on it. In a way, it's a show stopper bug. However, the chances of users clicking on this

link are very low so this bug can be fixed later and is not really high priority. A high priority bug would be one

which impacts the functioning/testing of application and needs immediate fix.

1. Interface bugs[low severity]user

    Eg1:Spelling mistake(High priority)

    Eg2:Improper alignment(Low priority)

2. Input domain bugs:[medium severity]

    Eg1:Doesnot allow valid values(high priority)

    Eg2:allows invalid type also(low priority)

3. Race condition bugs[High severity]

    Eg1:Deadlock(High priority)

    Eg2:improper order or services(Low priority)

Category                 Severity              Priority

Interface bugs              low                    High           e.g.  Spelling mistake

                                                           Low            e.g.  improper alignment       

                           

Input domain bugs       Medium              High        e.g.   Doesn’t allow values

                                                          Low       e.g.   Allow invalid type also                       

Race conditions bugs’    high                 High          e.g.   Deadlock

                                                           Low          e.g.   Improper order or service