How to prioritize bugs?

Question

In my current company there isn\'t clear understanding between the test and development teams as to how severe a bug should be? There are arguments which go back and forth to re

Answer 1

Some stuff we used before. We split the defect rating into priority and severity.

Severity (set by submitter during submission of defect)

• Highest (5): Data loss, hardware damage possible, or a security-related failure
• High (4): Loss of functionality without any reasonable workaround
• Medium (3): Loss of functionality with a reasonable workaround
• Low (2): Partial loss of a function or a feature set (feature still hits the design requirements)
• Lowest (1): A cosmetic error

Priority (adjusted by development, management and QA during defect evaluation)

• Highest (5): The system is practically unusable with this defect.
• High (4): The defect will have a serious impact on the company’s ability to sell and maintain this system.
• Medium (3): The company will lose some money if this defect is in the system, but it might be more important to meet the schedule. Fix after release.
• Low (2): Do not delay the release, but do fix this problem afterwards.
• Lowest (1): Fix as time and resources allow.

Both numbers together create a risk priority number (RPN). Simply multiply severity with priority. Higher result means higher risk. 25 defines the ultimate defect bomb. 1 can be done during idle time or if someone is bored and needs something to do.

First goal: Defects with a rating of highest or high of any kind should be fixed before release. Second goal: Defects with RPN > 8 should be fixed before releasing the product.

---

This is of course a little bit artificial but helps to give all parties (Support, QA/Test, Engineering, and Product Managers) a tool to set priorities without blowing away the opinion of other side.