The Complete Guidance for Priority and Severity with Examples...

The words Priority and Severity do come up in bug tracking. A variety of commercial, problem tracking/management software tools are available. These tools, with the detailed input of software test engineers, give the team complete information so developers can understand the bug, get an idea of its "Severity", reproduce it and fix it. The fixes are based on project "Priorities" and "Severity" of bugs. The "Severity" of a problem is
defined in accordance to the customer’s risk assessment and recorded in their selected tracking tool. A buggy software can "Severely" affect schedules, which, in turn can lead to a reassessment and renegotiation of "Priorities".

The effect of a bug on the software does not automatically correlate with the priority for fixing it. A severe bug that crashes the software only once in a blue moon for 1% of the users is lower priority than a mishandled error condition resulting in the need to re-enter a portion of the input for every user every time.

Therefore, track priority and severity separately, then triage appropriately. It helps to have input from others on the team on priority. The importance of a bug is a project decision, different from the bug's perception by the Customer. In some cases it makes sense to track Urgency, the customer's point of view, separately.
Microsoft uses a four point scale to describe Severity of bugs. Sev 1 is a crash or anything that loses persistent data , i.e., messing up your files on disk. Sev 2 is a feature that doesn't work. Sev 3 is an aspect of a feature that doesn't work. Sev 4 is for purely cosmetic problems, misspellings in dialogs, redraw issues, etc. This system works very well. (Interestingly, sev 4 bugs end up getting set to priority 1 fairly often, because they are frequently very annoying to users, and fixing them is generally easy and doesn't destabilize things.)
Keep clear the difference between severity and priority. The example given says a start-up splash screen with your company logo backwards and the name misspelled is purely a cosmetic problem. However, most companies would treat it as a high-priority bug.

It can be possible that if a bug has high severity and low priority then it need not to be fixed urgently whereas when a Bug has high priority then it should be fixed very urgently.



Q. What is Priority and Severity and What’s the difference between priority and severity?


Severity :


- Severity means Impact of Bug/Defect/Issue on the Application/Software.

- Severity describes the bug in terms of functionality.

- Severity is associated with standards.

- Severity decided by checking that how much Bug is impacting the functionality of the system.

- Severity is based on the impact or effect of the bug on application.
- Severity can be
Critical, Major or Minor.

- The amount of damage it (Bug) could cause is its severity.

- Severity is assigned by the Tester.

- Severity describes the seriousness of the bug.

- Severity means Technical (i.e if the application is shuts down when we perform one function in the Application the severity level is high)

- Severity can be stated as : Showstopper, Major, Minor, Cosmetic

Setting values for these four categories can be again defined by the organization based on their views.

1. Showstopper : This have a higher severity as you cannot proceed further testing with the application testing.

2. Major (High) : If there are any main defect based on the functionality .

3. Minor (Medium) : If there is any error in the functionality of one object under one functionality

4. Cosmetic (Low) : Any error based on the look and feel of the system,or improper location of the object(something based on the design of the web page)


For Example:


Bug 1: If Application button is clicked then it should open the application form page. If the button click does not work then it can be described as Severity is high.

Bug 2: If the click of Application button opens the application page but the details needs to be displayed in the current page are not displayed then it can be described as Severity is medium.

Bug 3: If the caption of the Application button is misspelled as Aplication then it can be described as severity is Lo.


Priority :


- Importance of Bug/Defect/Issue to fix before release.

- Priority describes the bug in terms of customer.

- Priority decided by checking the Importance of Bug.

- Priority is associated with scheduling.

- Priority means something is afforded or deserves prior attention; a precedence established by order of importance (or urgency).

- Which may not be a Bug, but it may have high priority b’coz that need to be fixed before release.

- Priority based on how urgently a bug should to be fixed.It is based on functionality of the application.
- Priority can be High, Medium or Low.

- The importance of Bug is its Priority.

- Priority means Business (If we are going to deliver a build in that build defect may be low severity but the Priority is high.)

- Priority will be set by the Team Lead or the Project Manager.

- Based on the Severity and the Time constraint that the module has the Priority will be set.


For Example:


- In the above Example (Given in Severity) if the application module need not be submitted immediately then Bug 1 and Bug 3 may be given high Priority where as Bug 2 may be given Priority Low.

- In the above case if the application module has to be given immediately then all the three bugs Bug 1, Bug 2 and Bug 3 are given High Priority.



Lets understand by real time bugs


1. If bug stops testing of Application

Severity = Critical and Priority = Very High.
2. If bug breaks major functionality

Severity = Major and Priority = High
3. Cosmetic (UI) Issues (Spelling mistakes, Alignment Problems and Color mismatches etc)

Severity = Minor and Priority = Low.
4. Bug in incomplete implemented functionality

Severity = Major and Priority = Low.
5. Bugs like customer logo not loading on page, Application flow diagram not shown correctly etc.

Severity = Minor and Priority = Very High.


Examples :


1. Low Severity & High Priority :


Example 1 : On any Log In Screens, “OK” button have text “KO”

Now try to understand, Button is working fine, means No functionality is affecting by that, it means its a minor Severity Bug.
But…
User will not understand what is “KO”. Because of this their application has no use, and they can’t release the product without fixing the bug. This is the High Priority bug.


Example 2 : If there is a spelling mistake or content issue on the homepage of a website which has daily hits of lakhs. In this case, though this fault is not affecting the website or other functionality but considering the status and popularity of the website in the competitive market it is a high Priority fault.


Example 3 : If a company logo is not properly displayed on their website.



2. High Severity & Low Priority :


Example 1 :Suppose you have an application which is having functionality of exporting to Excel File. But that functionality is totally not working. So in this case the Severity is Very High. But for current release this functionality is not useful, means user may not use the Export function, so here is have Low Priority

Example 2 : Supposing, you try the wildest or the weirdest of operations in a software (say, to be released the next day) which a normal user would not do and supposing this renders a run -time error in the application, the severity would be high.The priority would be low as the operations or the steps which rendered this error by most chances will not be done by a user.


Example 3 : If we have a typical scenario in which the application get crashed, but that scenario exists rarely or if that application crashes after multiple use of any functionality



3. High Severity & High Priority :


Example 1 : A bug which is a show stopper.i.e, a bug due to which we are unable to proceed our testing. An example would be a run time error during the normal operation of the software. Which would cause the application to quit abruptly.

Example 2 :
Suppose you are doing online shopping and filled payment information, but after submitting the form, you get a message like "Order has been canceled."

Example 3 : If there is a fault while calculating weekly report. This is a high Severity and high Priority fault because this fault will block the functionality of the application immediately within a week. So it should be fixed urgently.


4. Low
Severity & Low Priority :

Example 1 :
There is a mistake like "You have registered success" instead of successfully, success is written.

Example 2 :
If there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low Severity and low Priority.











Thanks & Regards ,

Prashant Vadher | QA Engineer


3 Comments:

Sanjay Naika said...

I have one doubt. As per the Priority definition, for those bugs which need to be fixed in later releases, we should assign the low priority level.

If you have a bug that's a medium or high - but not for the current release - then check your bug tracking software to see if you can assign a target milestone/release/version/whatever to it. It may not be a priority for *this* release, but you want to be able to mark it appropriately for future releases so it doesn't fall through the cracks.

Prashant Vadher said...

It isn't that the functionality is not required in a particular release that causes the issue to be deferred to a later release.

It is either that the probability of the issue reoccurring is so slight, or that the impact to the user is so small, that it can be deferred. For example, a spelling error on a seldom used dialog might be postponed to a further release.

Samir Gandhi said...

I would say if it is an established language to the developer, it is fine to adopt any system.

In my practice, severity rating are formed up using 2x2 matrix of exposure and impact of an issue.
Hence, the final rating, I would say already depicts the urgency of an issue. Tackling the issues by prioritizing the severity level seems sound to me and less complex to the developers.

Post a Comment

 
Design by Prashant Vadher