Page 1 of 3 123 LastLast
Results 1 to 10 of 23

Thread: Define severity

  1. #1

    Define severity

    Hi all,

    Is it a right way to define severity>>>>.
    I define it :
    Define severity:

    Severity is the measure to determine how bad a bug or a defect is........

    Is it a right definetion for severity or not..........

    Thanks in advance

  2. #2

    Re: Define severity

    No, it is a numerical representation of what is basically an opinion of how serious a bug is. As proof, you can see the severity debated in test status meetings. If it was a measure, it would be a fixed result (as in weight, length, volume, or any other measure).
    Frits Bos, PMP

  3. #3

    Re: Define severity

    It´s an easy concept, but hard to define in a company, for instance:

    Bugs that express some kind of crash should be defined as 1;
    Bugs that decreases performance 2, and so on.
    These definitions deppends on the company´s policies and also the kind of software you develop.
    The size of the company is a variable too.

  4. #4
    Super Member
    Join Date
    Oct 2001
    Bucharest, ROMANIA

    Re: Define severity

    I would define it as a measure of the deviance from user's requirements.

    "How bad the bug is" I would NOT use, because it's usually influence by the impact on business, which is a different thing.

    I will come back later with some examples.
    Don't worry, be Happy!

  5. #5

    Re: Define severity

    I've always defined severity according to the following:

    Level 1 - Critical. The user/tester is unable to use the application.

    Level 2 - Serious. The user/tester is unable to use some portion of the system, but is able to use other portions of the system. For example, maybe I can add a customer record, but I can't delete a customer record.

    Level 3 - Standard. Although the user/tester is inconvenienced, there is a workaround for the error and the user/tester is not prohibited from working on the system. For example, maybe I can't get to a certain screen by selecting the appropriate icon. I can, however, get to that screen through the menu. As the screen is accessible, the error is not serious or critical; merely inconvenient. This is also a good example of an error that would probably get a higher priority level than severity level (see below).

    Level 4 - Cosmetic. The error has no functional impact on end users. This included misspellings, wrong colors, lists in the wrong order, etc.

    These categories seem to be well understood by project teams and little debate occurs over their use. At the same time, these are severity, not priority levels. Priority levels prioritize the errors according to <some> standard; they may be placed in order of importance to the user, for example. Priority levels don't always match severity levels; what is a major priority for a user may not be a priority for development, and vice versa.

    - Linda

  6. #6

    Re: Define severity

    I agree with Linda's use of Levels. However severity like everything else in life is relative. I firmly believe that the actual discription of each severity level must be established by the client or end user. In Linda's chart a cosmetic item is a 4. However if your company name is consistantly misspelled or if a misspelling results in an inappropriate word... that would warrant a higher priority / severity. Another example is if the defect causes a client to view another clients information. That doesn't hamper your ability to use the system, but knowing others can possible see your data would warrant the client rating this a 1.

  7. #7
    Senior Member
    Join Date
    Apr 2003
    Wisconsin, USA

    Re: Define severity

    I too agree with Linda's use of severity levels. However, Art, I usually get disagreement when people confuse severity with priority. You almost use severity and priority as interchangeable items in your post.

    I give them an example of an order management system that has a yearly price increase function. The function does not work. Severity is obviously 1 for them. However, priority will depend on when the defect is found. If it is found in February and the functionality won't be needed until next January, priority is low. If it is found in December, priority is obviously much higher. Priority will change in this example, while severity will not.

  8. #8

    Re: Define severity


    Ofcourse all ur replies go with SEVERITY.But it can be explained in a better way as,

    A bug has severity:

    Blocker :Blocks development and/or testing

    Critical :Crashes,loss of data,severe memory leak

    Major :Major loss of function

    Normal :This is the run of the mill bug

    Minor :Minor loss of function, or other problem where an easy workaround is available

    Trivial :Cosmetic problem like misspelled words or misaligned text

    Enhancement :Request for enhancement

  9. #9

    Re: Define severity

    The Severity definition in the previous post is copied out of the Bugzilla help manual, and the definition of Trivial always irritates me:

    Trivial :Cosmetic problem like misspelled words or misaligned text
    <font size="2" face="Verdana, Arial, Helvetica">1. Cosmetic problems are not always trivial (company name mispelled!) I'd even go as far to say that most cosmetic problems are not trivial (like poor colour choice in a GUI)

    2. Plenty of trivial problems are worth recording, even though they are not be 'cosmetic'. If a piece of software has enough small problems, your confidence in it is pretty dented.

    I had to get that off my chest!

    jparrot99 at gmail.com

  10. #10

    Re: Define severity

    Its never easy to get criteria exactly spot on for severity, however it's important to spend time and get it right first time round since you don't want to classify I whole load of bugs with one citeria, then to change the criteria and log more with the new one.

    Get something down on paper and go through some old bugs and see if your classification works well. Ammend if necessary until you are happy with the classification before using it in production.

    I think I've drifted off the point a bit as the original questions was asking for a definition. Despite the use of "bad" and "measure", I think the original definition posted isn't too far off the mark.


Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
BetaSoft Inc.
All times are GMT -8. The time now is 07:36 PM.

Copyright BetaSoft Inc.