Blog

Generally speaking, software defect is an error, flaw or failure in a computer program or system that causes it to produce incorrect results and behave in unexpected ways. James Bach, a software tester credited with developing session-based testing, defines software defects as “any threat to the value of the product to any stakeholders who matter”. 

Most defects occur because of the mistakes in program design, source code, or in the operating systems on which the program is running. While QA experts put constant effort into preventing defects occurring in software programs, software defects in products are still a routine occurrence. For a software system or program to perform its functionality accurately, it needs to be 100% bug-free.

Finding and Removing Defects

An organized and directed defect management effort is required to identify and remove the defects in a program. Generally, bug management comprises of the following two methodologies: testing, and debugging.

Testing

Testing is the process of finding defects in a piece of code or a system. The system is tested against given and unexpected requirements while the resulting behaviors of the system are noted.

Testing can be of two types, manual and automated.

Debugging

Debugging is the manual process of finding and removing a specific bug or defect from a program. 

Defect Classification

Defects are given a priority and severity level to help the development team understand the defect level and extent. Defect classification is essential and is absolutely needed as the development team cannot resolve all the defects simultaneously. This classification allows the development team to decide which defects need to be fixed on an immediate basis and to what extent the functionality of the program is affected by the defects.

Defect Priority

How quickly a defect needs to be fixed is determined by defect priority. If there is a major bug in the program, its priority would be listed as “high”.

Priorities are described by words, such as “critical,” “high,” “low,” or “deferred”. These priorities are described as follows:

• High: Fix the defect immediately. The system is unable to perform its core functionality, or test execution is blocked by the defect.

• Medium: Fix the defect soon. The system fails to perform functionality, and the test execution is not blocked.

• Low: Fix “High” and “Medium” priority bugs before fixing this one but don’t neglect this bug as it needs to be fixed too.

• Deferred: The bug prioritized as deferred means that the bug is most likely to be fixed in the upcoming releases. The reasons behind this may be that the priority of the bug is low and there is a lack of time for the release, and/or the bug does not make a major effect on the functionality of the software.

Defect Severity

Defect severity indicates the extent to which the defect affects the program. In other words, it describes the impact of the defect on the system.

If an important functionality is blocked or if that functionality functions incorrectly, the highest defect severity is chosen.

Defect severity is an important feature in the bug management tools as it enables the project managers and teams to determine the priority level of the issues, thereby enabling them to triage the bugs accordingly.

Owing to this feature, the bug tracking, monitoring, and management system becomes more systematic and organized, and managers have increased traceability access.

Moreover, bugs and defects in the system can also be allocated to the team members with the most relevant skills and experience; for instance, a high priority bug that has a significant impact on the project and is more technical in nature would be assigned to a developer who has the most skills, experience, and bandwidth at the time.

In addition to this, depending on the severity, impact, and frequency of the bugs, the financial resources and testing efforts can be divided and assigned.

A critical bug that has no possible workaround and impedes the system’s functionality would be allocated a higher budget than a minor bug which can be ignored for the moment. 

Defect severity can be of the following types:

• Critical: A core functionality of the system fails or the system doesn’t work at all.
• Major: This defect has an impact on basic functionality and the system is unable to produce required results.
• Moderate: The defect causes the system to generate false, inconsistent, or incomplete results.
• Minor: There is an impact on the business, but only in very few cases.
• Cosmetic: The defects that are related to the interface and appearance of the application.

While the above-mentioned priority and severity levels can vary among different companies and test engineers, their usage remains the same. Assigning a defect priority and defect severity is always subjective to the test engineer who measures the impact of the defect from their point of view. Nevertheless, the defect priority and severity must be set carefully because its resolution is both costly and time-consuming.