Defect criticality

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 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