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