Classification Of Errors By Severity

Classification of Errors by Severity Often the severity of a software defect can vary even though the software never changes. The reason being is that a software defect’s severity depends on the system in which it runs. For example, the severity of the Pentium’s floating-point defect changes from system to system. On some systems, the severity is small; whereas on other systems, the severity is high. Another problem (which occurs regularly) is that the definitions of the severity levels (or categories) themselves change depending on the type of system. For example, a catastrophic defect in a nuclear system means that the fault can result in death or environmental harm; a catastrophic defect in a database system means that the fault can (or did) cause the loss of valuable data. Therefore, the system itself determines the severity of a defect based on the context for which the defect applies. The context makes all the difference in how to classify a defect’s severity. I have attached two sample classification methods – a 3 level classification method, and a more comprehensive 5 level classification method, which I hope you may find useful.

3 Level Error Classification Method Errors, which are agreed as valid, will be categorised as follows :•Category A - Serious errors that prevent System test of a particular function continuing or serious data type error •Category B - Serious or missing data related errors that will not prevent implementation. •Category C - Minor errors that do not prevent or hinder functionality.

Explanation of Classifications 1. An "A" bug is a either a showstopper or of such importance as to radically affect the functionality of the system i.e. : 

If, because of a consistent crash during processing of a new application, a user could not complete that application.



Incorrect data is passed to system resulting in corruption or system crashes

Example of severally affected functionality: 

Calculation of repayment term/amount are incorrect



 Incorrect credit agreements produced

2. Bugs would be classified as "B" where a less important element of functionality is affected, e.g.: 

a value is not defaulting correctly and it is necessary to input the correct value



data is affected which does not have a major impact, for example - where an element of a customer application was not propagated to the database



there is an alternative method of completing a particular process - e.g. a problem might occur which has a work-around.



Serious cosmetic error on front-end.

3. "C" type bugs are mainly cosmetic bugs i.e.:



Incorrect / misspell text on screens



drop down lists missing or repeating an option

5 Level Error Classification Method

1. Catastrophic:

2. Severe:



Defects that could (or did) cause disastrous consequences for the system in question.



E.g.) critical loss of data, critical loss of system availability, critical loss of security, critical loss of safety, etc.

Defects that could (or did) cause very serious consequences for the system in question. E.g.) A function is severely broken, cannot be used and there is no workaround.

3. Major:

Defects that could (or did) cause significant consequences for the system in question - A defect that needs to be fixed but there is a workaround. E.g. 1.) losing data from a serial device during heavy loads. E.g. 2.) Function badly broken but workaround exists

4. Minor:

Defects that could (or did) cause small or negligible consequences for the system in question. Easy to recover or workaround. E.g.1) Error messages misleading. E.g.2) Displaying output in a font or format other than what the customer desired.

5. No Effect:

Trivial defects that can cause no negative consequences for the system in question. Such defects normally produce no erroneous outputs. E.g.1) simple typos in documentation. E.g.2) bad layout or mis-spelling on screen.