Priority Vs Severity

Priority and S​everity are often the shaken debatable concepts and are almost​ interchangeably used between different people even within the test team. They both are attributes of a bug/defect and play important role in fixing the bug.

​Below I have put in some information which I have gained through experience and reading many blogs over many many years. Hoping this helps to clear confusions (atleast few) any individual may have:

What is Severity?​

Severity is an attribute which denotes the implicatio​​n of a bug/defect on the system – how critical the defect is and what is the impact of the defect on the system?. Impact is defined in terms of financial loss, damage to an environment, company’s reputation and loss of life​ etc​​. Severity is an attribute which is set by the tester.

Different Levels are:

1. Critical / Show Stopper (S1): A defect that completely hampers or blocks testing of the product/ feature is a critical defect. 

Ex:  in case of UI testing where after going through a wizard, the UI just hangs at one pane or doesn’t go further to trigger the function. 

2. Major or Severe (S2): A major defect occurs when the functionality is functioning grossly away from the expectations or not doing what it should be doing. 

Ex: A page crashes when user keys in alphabets in the telephone number field​​

3. Moderate/ Normal (S3): A moderate defect occurs when the product or application doesn’t meet certain criteria or still exhibits some unnatural behavior, however the functionality as a whole is not impacted. 

Ex: Few cases of spelling mistakes 

4. Low or Minor (S4): A minor bug occurs when there is almost no impact to the functionality, but is still a valid defect that should be corrected. 

Ex: Spelling mistakes in error messages shown to user or defect​s to enhance the look and feel of a feature.​​

​

What is Priority?

Priority of a defect is related to how quickly it should be fixed ​and it defines the order in which the defect should be fixed. ​

Different Levels can be as below and these priority generally varies depending upon the type of the project and audience of the system:

• Priority 1 – Critical (P1): Must be fixed in the next build​​. 
• Priority 2 – High (P2): Must be fixed in any of the upcoming builds but should be included in the release​​.   
• Priority 3 – Medium (P3): May be fixed after the release / in the next release​.​
• Priority 4 – Low (P4): May or may not be fixed at all​.​

Priority is quite a subjective decision; however, it can be determined by considering the following:

• Severity/Impact
• Probability/Visibility
• Business need for fixing the defect​​
• Availability of time

What is ​Defect Probability?

Defect Probability (Defect Visibility or Bug Probability or Bug Visibility) indicates the likelihood of a user encountering the defect / bug.

• High: Encountered by all or almost all the users of the feature
• Medium: Encountered by about 50% of the users of the feature
• Low: Encountered by very few or no users of the feature​​

Followig table can be used as a guidance to determine the Priority of the defect in conjunction with Severity and Probability of the defect:

​Severity/Probability​​​	​​​​​High	​Medium	​Low
​Severity 1	​P1	​P2	​P3
​Severity 2	​P1	​P2	​P3
​Severity 3	​P2	​P3	​P4
​Severity 4	​P2	​P3	​P4​

Differences between Defect Priority and Defect Severity​

Defect Priority	Defect Severity
Priority defines the order in which the defects should be resolved	It is defined as the degree of impact that a defect has on the operation of the product
Priority is categorized into three types o    Critical o    High o    Medium o    Low​	Severity are categorized into five types o    Critical o    Major o    Moderate or Normal o    Minor or Low
Priority is associated with scheduling	Severity is associated with functionality or standards
Priority indicates how soon the bug should be fixed	Severity indicates the seriousness of the defect on the product functionality
(Usually) Priority of defects is decided in consultation with the manager/client	Tester determines the severity level of the defect
Priority is driven by business value	Severity is driven by functionality
Its value is subjective and can change over a period of time depending on the change in the project situation	Its value is objective and less likely to change​
Priority status is based on the customer requirements	Severity status is based on the technical aspect of the product

Few examples of bugs with different Priority and Severity:

High Priority & High Severity: An error which occurs on the basic functionality of the application and will not allow the user to use the system. (Eg. A site maintaining the student details, on saving record if it, doesn’t allow to save the record then this is high priority and high severity bug.)

High Priority & Low Severity: The spelling mistakes that happens on the cover page or heading or title of an application.

High Severity & Low Priority: An error which occurs on the functionality of the application (for which there is no workaround) and will not allow the user to use the system but on click of link which is rarely used by the end user.

Low Priority and Low Severity: Any cosmetic or spelling issues which is within a paragraph or in the report (Not on cover page, heading, title).​​​