11

I understand what they determine but is it really useful to assign those to issues found? I mean, it is either required to fixed quickly or not.

I know how to set them, categorize them etc. I know IEEE/ISO do require to do that. I just do not see why.

  • Hmm, I think a bug that would damage data is more severe than something that is just annoying like say some functionality taking too long to load. Both should be fixed but those with higher negative impact should be fixed first. – thorsten müller Dec 1 '15 at 9:43
  • No, as I wrote I know what they are or how to set them. I just do not se ethe benefit. – Pietross Dec 1 '15 at 9:56
  • 5
  • In most cases, no. But there are always edge cases where it makes sense to separate the two. Whether the separation is worth maintaining for every issue just to cater for those rare occasions is another matter. – biziclop Dec 1 '15 at 11:49
  • 1
    You can have a UI bug that doesn't really affect he apps usability (low severity), but is a high priority because it's ugly. You can have a bug that crashes the app completely (high severity) but is a low priority because the conditions to make it happen are one in a million and in all practical terms will never actually happen (this ignores the fact that one-in-a-million chances come up nine times out of ten). – Binary Worrier Dec 3 '15 at 20:47
21

It is absolutely possible to have those values differ. If you have a sale to make to an important government agency that requires high performance but won't ever use module X, then it makes a lot of business sense to fix a minor database availability error sooner than a severe error in the X module. Basically, technical reasons are not the only factor when you run a software business.

  • Exactly: Priority indicates business value and is the result of project management. Severity indicates impact and is the result of bugs. Every task can have a priority, but e.g. new features don't have a severity. Aside from security-critical high-severity bugs, it would be foolish to let severity alone dictate priorities, or people would be mis-incentivized to overstate their issue's severity. – amon Dec 1 '15 at 13:22
  • 5
    I think the important thing is that only one measure (the priority) controls the order of development directly. How useful a team finds an additional "severity" as part of a defect description is extremely opionated: some might find it helpful, others like @arnaud think it is "bureaucracy" - both points of view might be reasonable. – Doc Brown Dec 1 '15 at 14:51
  • 3
    High Priority, Low Severity: The landing page of your application, seen by millions of users a month, has a typo in your company name. Low Priority, High Severity: System crashes 25% of the time on startup for an application that is being retired next week. – Steven Burnap Dec 3 '15 at 21:18
  • 2
    Severity can generally be determined by rules by automated and live testers. Priority can only be evaluated subjectively by the business. – Steven Burnap Dec 3 '15 at 21:20
3

Date and time bugs

Bug: Year-end processing will totally corrupt your database. That's clearly a severe bug.

Date: December 15. The bug is very high priority.

Date: February 1. The bug is low priority.


Accidental launch of missile bug

Bug: ICBM control software pukes when going from Feb 28 to Mar 1 in years divisible by 4. The result is an uncommanded launch.

That's about as severe a bug as can exist. Priority very low, though--is there any realistic chance the software will be in use when the condition is triggered?


Inadvertent 'bad' words on screen

Bug: Messages overflowing their space on the screen result in an inadvertent profane reference to Bob appearing. (Real world: We had people working in the "Final Ass" department. "Ass" = "Assembly".)

Unfortunately, tomorrow you are making a presentation where getting the sale is make-or-break for the company. You are making the presentation to someone named "Bob". Severity: Very low. Priority: Very high.

  • Related to the 'overflow' and 'date time' bugs you mention - you may enjoy phase of the moon bug – user40980 Dec 7 '15 at 21:20
0

You wrote:

I mean, it is either required to fixed quickly or not.

That is correct. If you are like most companies, however, your resources are limited. Either you don't have enough people to fix all of the issues, or you don't have enough time.

Given the fact that a bug is either required to be fixed quickly or not, and you have lots of bugs that need to get fixed, "priority" answers the question "which one do I fix first"?

Severity, on the other hand, is an indicator used by the person setting the priority. From a developer's point of view the severity is a moot point. From the perspective of the one assigning work, severity is an important piece of information that helps with the decision making process.

Of course, all of this is very general information. If you are a team with an impossibly long backlog of bugs, priority and severity mean something completely different than if you are on a team that has a near-empty bug database.

If you're on a team where "high severity == high priority" none of this matters and you don't need both metrics. At the end of the day, these are just tools. Your team needs to decide how to use them. For your team it may not make sense to use both.

0

IMHO, putting both Priority and Severity is just bureaucracy.

In practice, you just need one measure of "importance". Often, priority is used for it, and severity is then used as technical term like "high = crashes system or makes it unusable", "medium = buggy behavior, potentially harmful", "low = nuisance, annoying but harmless"

Usually, priority goes hand in hand with severity. A few counter examples are a "nuisance where everyone always complains" or a "crash having occured once in an exotic environment".

...but, in the end, as a developer (or manager, etc) you only need to know in what order you should fix/improve things, that's all. So one measure is enough.

The need of priority is clear: it's to know in what order the bug reports should be tackled. The other one, IMHO as usual, is bureaucracy. Why do you need it? It's apparently useless for sorting because priority does that. And the consequences (severity description) is described in the bug report anyway.

I even think it is harmful because it makes it less clear what bug is more important:

  • Some may think a "critical" bug has higher priority than a "high-priority" bug.
  • Some users reporting a bug may confuse severity and priority
  • ...altogether, it rather adds confusion as to what order the bugs should be tackled
  • 1
    And are developers the only people that matter? – biziclop Dec 1 '15 at 11:50
  • 2
    @biziclop Nope, you are right, it was a poor formulation of mine. It holds for everyone: what matters, for managers, etc, too, is what should be fixed first, and what is less important. For that, one measure is enough. – dagnelies Dec 1 '15 at 12:10
  • 1
    Well, it is wrong from risk management perspective - priority=severity*rate of occurrence. Is a typo on the frontp age lower priority than a fatal server crash that happens if user last name exceeds 46 characters? – Pietross Dec 1 '15 at 12:58
  • 1
    @Pietross: well, you pinned it down: which one should be tackled first? The low priority sever crash or the high priority nuisance? How do you prioritize? Who makes that judgement call? Everyone looking at the list? When using only one priority measure, it prioritized once, then it's done. The impact and severity is described in the bug report anyway. – dagnelies Dec 1 '15 at 14:04
  • The thing about "severity" is you can pretty easily say "crash = high, typo = low". It takes thought to realize that a typo that leaves 'o' out of the word 'count' on the homepage is higher priority to fix than the page refusing to load at all. – Steven Burnap Dec 4 '15 at 1:24
0

In addition to other answers, consider this scenario: bug A will take 30min to fix and has 'low' severity; bug B may take 2+ weeks to fix and have 'high' severity. In addition, bug B may take a lot of discussion and coordination in dev team and perhaps outside of team; bug A may be fixed by single dev immediately. It's perfectly fine to set higher priority on bug A.

Of course 'severity' and 'priority' may be interpreted in different ways.

In a small bug tracker I made for my own use I instead preferred 'difficulty' and 'priority' where high severity issues would always have highest priority, and I might decide to delay working on them based on difficulty.

One thing I don't like about 'severity' is that it only applies to bugs and not features. It may be better to have a single list of all issues ordered by priority and difficulty as it's more directly helpful to decide 'what do I work on next?'.

-3

A simple example. Imagine the case you have a narrow place which prevents scaling of your system - some algorithm has complexity O(N^3), where N is count of client's stores. The client says it will open 200 new stores the next year, and the needed calculations (goods distribution, transportation planning, etc.) won't be finished in time. But, currently this client has only 30 stores, and resources are enough. The task to optimize this algorithm (to O(N^2) or better) is definitely important (you'll lose the client if not implemented), but likely not urgent: you have a few months to implement the new algorithm.

An opposite example: save some temporary data, which can be recalculated in a few hours, from automatic deletion. It's urgent because it will be deleted in a few minutes, but not important because recalculation is available and rather cheap. (Yep, this is not formally "a bug", but analogies can be easily defined.)

Of course, both parameters are unified using some metric (either formal or informal) to produce a short-term work plan, because the latter is single-dimensional (sequence of tasks). But in long term view they shall not be unified.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.