Defect criticality

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

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

References[edit]