Kalpana Kalpana (Editor)

Defect criticality

Updated on
Edit
Like
Comment
Share on FacebookTweet on TwitterShare on LinkedInShare on Reddit

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.

Contents

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

    • References

    Defect criticality Wikipedia
    (Text) CC BY-SA