Defect Severity In Software Testing

Feb 12, 2020

Flaws, defects or any minor issue in a software system can impact its success in the market. Though not all defects are as detrimental as others, it is important that the team determines the severity and the impact of the defect and prepare an appropriate mitigation plan. Through this article, we shall try and assimilate how a defect impacts the components of software by studying about Defect Severity.

What Is a Defect?

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.

Meaning of Defect Severity

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.

Features of Defect Severity:

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:

The severity level of defect indicates the potential business impact of the ends user.
Defect severity indicates the quality of the software under test (SUT).
This information is used to make the release decision based on the number of defects and their severity.
It is related to the technical aspect of the product.
The classification of a defect based on its impact on the functionality and the operation of the system is known as severity.
If a functionality is blocked or if it functions incorrectly, it is allotted the highest defect severity.

Reasons for Defining Severity of Defect:

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:

It assists the testing teams to determine the efficiency of the testing process.
Helps the Quality Assurance team determine the defect priority and severity, which enables them to test higher priority defects first.
Increases the efficiency of bug tracking, which further improves the quality of the product.
By defining the defect severity we can identify the aspects of the software that functions incorrectly.

Defect Severity: Info-graphics

Who Tests For Defects?

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.

Types of Defects

Defects are classified into 4 main types based on the severity of their impact. These are:

Critical – These are those errors which result in complete failure, for example, unable to load software, etc. Such errors prevent any further testing as they do not have a workaround. Symbolically, critical errors are denoted by S1.
Major – A major defect is that which collapses or crashes the system and yet there are a few functionalities that remain operable. The workaround in such cases is not impossible but it is very difficult. Such errors are denoted by the symbol S2.
Minor – Such defects have an impact on the less important data and minor functions. It can cause some malfunction but will still keep the software up and running. The workaround is easy and obvious. Minor defects are denoted by the symbol S3.
Trivial - These errors do not relate to the data or working of the software. In fact, trivial errors are those that relate to the look and feel of the program. These errors do not cause malfunctions by impacting any data or function. Trivial errors are denoted by the symbol S4.

Things to Consider While Defining the Priority and Severity Levels of the Defect:

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 :

Decide the impact of the defect, as a defect that may seem minor to the test engineer might be a high priority defect for the users.
It is important to isolate the defect to find out its depth of impact.
Analyze the defect to determine what class of inputs does defect supports.
Make sure that the defect occurs only with a particular sequence of operations.
List the all the sequence which cause the defect.

Caution To Be Exercised While Testing Defect Severity:

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.

Difference Between Defect Severity & Defect Priority:

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 priority, read or next article Severity vs Priority.

Conclusion

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.