A defect is a shortcoming, an imperfection or a flaw in any system, which deviates the actual result from the expected one. Moreover, when the result does not meet the requirements or expectations of the end user, it is termed as a defect, error, or a bug.
In software testing, Defect Severity is the impact that a defect has on either the development or execution of any program. It is the degree of impact that a defect has, on the application.
The higher the degree of impact or severity, the more detrimental the error will be. In short, defect severity during the process of software testing depends on how important the tested function is and whether it is meeting the defined requirements of the client or not.
Defects play an important role in the Software Development Life Cycle (SDLC) and can impact the performance and the functionality of the product. It is with the assistance of defect severity that the QA team is capable of resolving the critical defects & issues in the system and preparing a defect-free software.
Other features that make defect severity an integral part of STLC are:
From ensuring that the defects are fixed immediately to defect classification and assisting the development teams in accurate software development, defect severity serves an important part in the software testing life cycle (STLC). Other features that define defect severity are:
Every software undergoes comprehensive testing before it can be launched. The purpose of these various tests is to find and remove defects. When it comes to testing, it can be done by either the code developers themselves or the testers, as the case may be.However, when it comes to defining the severity of the defects, it is the responsibility of the Quality Assurance team to evaluate the defects and determine their severity.
Defects are classified into 4 main types based on the severity of their impact. These are:
While defining the priority and severity levels of the defect, it is important for the team to consider the following points, which can help them in defining the severity of the defects :
Great caution needs to be exercised while checking for the severity of a defect. This is because even a minor oversight can make a critical error trivial and vice-versa. Also, when it comes to the war of words between the developers and the testers, it has often been seen that the developers do not agree with the findings of the testers in terms of the impact that a defect can have. This problem can, however, be overcome by setting some mutually agreed upon standards.
|Defect Severity||Defect Priority|
|1. Defect severity is defined as per the degree of impact that a defect has on the operation or functionality of a software product.||1. Defect priority is defined by the order in which a software developer resolves a defect or a bug in a software product.|
|2. It is associated with the software functionality or standards.||2. It is associated with the scheduling of defects in the software.|
|3. The QA engineers have the final say on the defect severity.||3. Product management or the client has the final say on defect priority.|
|4. Severity indicates the seriousness of the defect on the functionality of the product.||4. Priority indicates how soon a defect, bug or any other discrepancy in the software is rectified.|
For a detailed differentiation between defect severity and defect priority, read or next article Severity vs Priority.
Calculating the Defect severity is the best way of prioritizing corrective action and its implementation. Obviously, a critical error needs to be addressed first and foremost, subsequently moving down the line, so that a superior quality software can be developed and delivered to the client and the end user.