Jump to content

Defect criticality

From Wikipedia, the free encyclopedia

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]

Class 1

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

Class 2

[edit]

Class 3

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

Class 4

[edit]

Assessing the criticality score

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

References

[edit]