Defect criticality

Short description: Measure of the impact of a software defect

In the context of software quality, defect criticality is a measure of the impact of a software defect. It is defined as the product of severity, likelihood, and class.

Defects are different from user stories, and therefore the priority (severity) should be calculated as follows.

Severity/impact

• 0 - Affects critical data or functionality and leaves users with no workaround
• 1 - Affects critical data or functionality and forces users to employ a workaround
• 2 - Affects non-critical data or functionality and forces users to employ a workaround
• 3 - Affects non-critical data or functionality and does not force users to employ a workaround
• 4 - Affects aesthetics, professional look and feel, “quality” or “usability”

Likelihood/visibility

• 1 - Seen by all or almost all users who use the application (>=95% of users)
• 2 - Seen by more than 2/3 of the users who use the application (>67% and <95%)
• 3 - Seen by about half the users who use the application (>33% and <66%)
• 4 - Seen by about 1/3 or less of the users who use the application (>0% and <32%)

Class of defect

Class 0

• Stability, Reliability and Availability
• Security
• Legal (Liability, ADA, Copyright)
• Testability
• Storage (data loss/corruption)

Class 1

• Performance and Efficiency (use of resources: memory, disk, CPU)
• Scalability

Class 2

• Functionality
• Logic or Calculation
• Compatibility
• Interoperability

Class 3

• Usability
• Learn ability
• Readability
• Documentation
• Consistency
• Workflow (“feel”)

Class 4

• Typographic or grammatical
• Aesthetics
• Appearance or Cosmetic

Assessing the criticality score

• 0–2 = Critical
• 3–9 = Major
• 10–20 = Medium
• 21–64 = Low