Assuming you are involved in evaluation of bugs in your organization, how do you define the different levels of severity of these bugs?
More specifically - What are the different values do you use for "Severtiy"? What are the criteria that you use to assign the values to the bugs?
Clarification: I'm only talking about the symptoms here. Let's put aside other things that affect prioritization like: how long it would take to fix the bug, what other tasks are on the team's agenda etc.
if we speak about money it's critical.
Then it depends on how many times it depends on many things :
time to resolve
how it change the productivity of the other employees
contract (if the bug breaks the contract it's critical)
if bad data are entered/selected from in the db it could be critical
It also depends on your business.
You basically need two things for this:
If you take these two into account then you will get a nice list of what to fix first.
A low-severity bug can have a high priority for example.
Each company is different. We have 5 different levels here
For the most part our business testers define the severity of the issue. As they do the testing and the run across a bug they determine how this will impact the customer and the potential release and assign a priority accordingly. We review the items that are the most severe and see if they really are as severe as the business is making them out to be. Several times the business testers have reported "Blocker" bugs, but when we dig into it we find it's really not that critical.
To sum it up, Blocker bugs are the bugs we need to fix immediately. These are the bugs that will prevent the product from working if it were released in that state.
Critical bugs are still bugs, but there is typically a workaround or a quick fix that can be applied post-release.
Major bugs have a workaround and can be put off without impacting the functionality of the application.
Minor and Trivial issues are usually reserved for enhancements or "nice to haves".
Hope this helps clarify things.