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.
YouTube Encyclopedic
-
1/3Views:2 74589 98526 080
-
Reliability Improvement: Establishing the Asset Criticality Ranking
-
Mobile App Testing for beginners Day 01. Mobile App Testing Tutorial for beginners android
-
HP ALM 11.52 Training
Transcription
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 does not force 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 of defect
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
This page was last edited on 3 May 2024, at 08:06