Defect Priority and Severity

What's the difference between defect priority and severity?  Is there a guide to setting a defect's priority and severity? Well, here's your answer!

Defect Priority and Severity Guides – The following tables will be used in determining priority and severity when reporting defects:

 

Defect Priority – Defect priority reflects the business impact of the defect on the end users of the application.  Priority is initially set by the QA team based on their understanding of the end user needs and will be reviewed and/or modified by the product owner once every two weeks

Defect Priority Guidelines
Priority	Definition
Priority 1	High
	1.       Critical area of the system and frequently used 2.       Very visible and/or detrimental to majority of customers 3.       Major impact to the customer 4.       No workaround 5.       Must be fixed prior to release
Priority 2	Medium
	1.       Critical area of the system 2.       Visible and/or detrimental to customers 3.       Major impact to the customer 4.       Workaround exists 5.       Should be fixed prior to release 6.       Can ship with after all stake holder have signed off
Priority 3	Low
	1.       Non-critical or infrequently used areas of the system 2.       Some customers are impacted 3.       Litter or no impact to the customer 4.       Little or no impact on product functionality 5.       Workaround exists 6.       Should be fixed if there are no other higher-priority issues 7.       Can ship without fix

Defect Severity – Defect severity reflects the technical impact of the defect within the application.  Severity is set by the QA team based on their understanding of the system and can be modified according to project team discussion

Defect Severity Guidelines
Severity	Definition
Severity 1	High
	1.       Entire application, component or function does not work or access is blocked by defect 2.       Errors related to security, confidentiality, legal or regulatory non-compliance 3.       Severe data loss or corruption in a critical component
Severity 2	Medium
	1.       Errors occurring in sub-components or functions for key business areas (e.g., Accounting transactions, Monetary calculations) 2.       Data corruption of a non-critical component 3.       Broken functionality that has a workaround
Severity 3	Low
	1.       Errors occurring in sub-components or functions for non-key areas (e.g., system data management) 2.       Application operations are unexpected, but don’t cause data corruption/loss (e.g., navigation on cancel; sorting inconsistencies) 3.       Cosmetic errors  (e.g., spelling, alignment, look and feel, formatting, unclear error messages)