DEFECT SEVERITY or Impact is a classification of software defect (bug) to indicate the degree of negative impact on the quality of software.
- severity: The degree of impact that a defect has on the development or operation of a component or system.
DEFECT SEVERITY CLASSIFICATION
The actual terminologies, and their meaning, can vary depending on people, projects, organizations, or defect tracking tools, but the following is a normally accepted classification.
- Critical: The defect affects critical functionality or critical data. It does not have a workaround. Example: Unsuccessful installation, complete failure of a feature.
- Major: The defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s.
- Minor: The defect affects minor functionality or non-critical data. It has an easy workaround. Example: A minor feature that is not functional in one module but the same task is easily doable from another module.
- Trivial: The defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. Example: Petty layout discrepancies, spelling/grammatical errors.
Severity is also denoted as:
- S1 = Critical
- S2 = Major
- S3 = Minor
- S4 = Trivial
Defect Severity is one of the most common causes of feuds between Testers and Developers. A typical situation is where a Tester classifies the Severity of Defect as Critical or Major but the Developer refuses to accept that: He/she believes that the defect is of Minor or Trivial severity.
Though we have provided you some guidelines in this article on how to interpret each level of severity, this is still a very subjective matter and chances are high that one will not agree with the definition of the other. You can however lessen the chances of differing opinions in your project by discussing (and documenting, if necessary) what each level of severity means and by agreeing to at least some standards (substantiating with examples, if necessary.)
Normally, Testers have the final say on Defect Severity while the Project Management / Product Management /Client has the final say on Defect Priority.
ADVICE: Go easy on this touchy defect dimension and good luck!
For more details on defects, see Defect.