Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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.
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.
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.
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?
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.
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.
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:
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?'.
I have designed and implemented processes in a software company that were certified ISO9001:2007. There have been updates to the standard since 2007 so there may be additional requirements that I am not aware of... however:
The ISO9001 standard is about ensuring that your company designs and implements processes that have feedback loops for improving the process when product and process defects are identified.
During the design phase the requirements focus on whether the proposed solution if implemented correctly would actually solve the design brief (validation) and checking whether the implementation actually has been implemented without defect (verification)
On the feedback loop, when defects are identified, it’s not enough that they are recorded. A defect also needs to be assessed for severity, and the rework prioritised.
The key part, is that how your particular company decides to assess its severity, and make decisions about priority is not defined by the ISO standard. It’s a commercial and governance issue for the company to decide and document.
As it is written into the standard as a requirement, any certified company will have a process around assessing the severity of a defect and a process in determining the priority of the work to fix the bug. They are definitely two seperate decisions that need to be made.
Severity of the bug is only one data point. Customer impact Is another data point. There’s also effort to fix, defect age, commercial life remaining in the product, and any other factor that the company decides to include in its decision making. The one thing it should not be written as “present defect to product manager to decide priority” as that only defines the authority to make the decision and does not define the process they they follow to make the decision.
I have a preference for prioritisation that is biased towards delivering a high rate of small and important changes, as this seems to provide the best boost to overall product reliability. This means that a severe bug that will take a lot of work to fix would need its work breaking down into smaller chunks to get sufficient priority to get scheduled.
For reason to strongly differ priority and severity:
A simple example. Imagine the case you have a narrow place that 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.
Example 2: an application crashes systematically, but this version gets out of usage in a few days due to upgrade or migration. Fixing is urgent because crashes really affect user experience, but is of low importance.
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.
