Defect criticality
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
|
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[edit]
- 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[edit]
- 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[edit]
Class 0[edit]
- Stability, Reliability and Availability
- Security
- Legal (Liability, ADA, Copyright)
- Testability
- Storage (data loss/corruption)
Class 1[edit]
- Performance and Efficiency (use of resources: memory, disk, CPU)
- Scalability
Class 2[edit]
- Functionality
- Logic or Calculation
- Compatibility
- Interoperability
Class 3[edit]
- Usability
- Learn ability
- Readability
- Documentation
- Consistency
- Workflow (“feel”)
Class 4[edit]
- Typographic or grammatical
- Aesthetics
- Appearance or Cosmetic
Assessing the criticality score[edit]
- 0–2 = Critical
- 3–9 = Major
- 10–20 = Medium
- 21–64 = Low