Friday, December 4, 2009

Bug priority and severity guidelines

Guidelines for assigning severity and priority to a bug

These guidelines are based on industry standards and my experience on what worked well in various projects/companies. These definitions and criteria should be tailored to best suit a specific project team

Severity vs Priority

Training the team on using two different fields for severity and priority in a bug tracking system could seem like an overhead, but ideally QA's definition of the impact of a bug (severity) should be kept separate from PM's decision on whether they want to make an exception depending on time constraints and defer it (priority/when to fix)

In the absence of such segregation, the priority field would be modified when a bug is triaged out of a release

*The term 'critical functionality' refers to new features deemed as acceptance tests by QA/Product Mgmt or existing features that impact customers the most

Severity/Priority assignment:

Severity: Critical/Show-Stopper
Priority: Must fix before Feature Complete (in agile context) /Code Freeze milestone/ Could be deferred to an immediate patch

1. Failure of critical functionality with no workaround
2. Data loss or corruption
3. Billing data or invoice display inconsistencies
4. Issues blocking testing
5. Critical functionality discrepancy between requirements and implementation
6. Critical functionality error handling failures with high occurence likelihood and resulting in high impact to customers
7. Security concerns with customer visibility


Severity: High
Priority: Should fix before code freeze (agile and waterfall context)

1. Partially impaired critical functionality with less than desirable workaround
2. Failure of non-critical functionality with no workaround
3. Non critical functionality discrepancy between requirements and implementation
4. High customer impact UI discrepencies
5. Security concern with no real customer impact


Severity: Medium
Priority: Attempt to fix before code freeze or deferred to next release (ie, release candidate should not be tainted for a medium priority fix)

1. Impaired non critical functionality with satisfactory workaround
2. Impaired critical functionality during low occurence edge cases
3. High impact spelling errors
4. Non critical functionality error handling failure


Severity:Low
Priority:If it may be fixed before code freeze else deferred to next release

1. Rare occurrence
2. Low customer impact feature failure
3. UI layout or low impact spelling errors