Priority and Severity of Defects

(Q). Why do defects have priority and severity?

Priority is defined as parameter that decides the order in which a defect should be fixed. Defect having the higher priority should be fixed first. Severity is a parameter to denote the impact of a particular defect on the software. Priority indicates how soon the bug should be fixed. Severity indicates the seriousness of the defect on the product functionality.

In Software Testing, Defect severity can be categorized into four class

Critical: This defect indicates complete shut-down of the process, nothing can proceed further.

Major: It is a highly severe defect and collapses the system. However, certain parts of the system remain functional.

Medium: It causes some undesirable behavior, but the system is still functional.

Low: It won't cause any major break-down of the system.

Defect priority can be categorized into three class

Low: The Defect is an irritant but repair can be done once the more serious Defect has been fixed.

Medium: During the normal course of the development activities defect should be resolved. It can wait until a new version is created.

High: The defect must be resolved as soon as possible as it affects the system severely and cannot be used until it is fixed.

Importance of Defect Management

(Q). Why is defect management process important in software development teams?

Defect management can be defined as a process of detecting bugs and fixing them. Hence, every software development project requires a process that helps detect defects and fix them. The process of defect management, or bug tracking, is usually conducted at the stage of product testing.

The process of defect management, or bug tracking, is usually conducted at the stage of product testing. Without realizing this it would be hard to understand is the nature of defect management. Software testing can be conducted in two different ways. Usually, the developers test their product themselves. However, there is also a type of testing that is based on user involvement. The final users are often provided with an ability to report on the bugs they found. Nevertheless, this is not the best way of testing, because the users could hardly find all bugs.

The process of defect management usually includes four steps:

1. The first step is the stage of defect detecting.  It can be conducted either by the team of developers or by the users. Regardless of the type of testing, its main goal is to detect all bugs in the final product or its part.

2. The second step of the bug management process is dedicated to the formulation of bug reports. These are the documents that include all necessary information about certain bugs. Usually, they contain data on the type of bug, and the possible ways of its correction.

3. The third step is the stage of bug fixing. After the bugs are fixed, they should be tested once more to make sure that the software works properly.

4. During the final step the bug list is created. This is the document that contains information about all bugs that occurred during the project’s performance. The team often uses the bug list because similar bugs’ occurrence is not rare.

Fields in Bug Report

(Q). What are the fields in a bug report?

Bugs can be reported in a number of ways. However, using a bug tracker is probably the best way for your organization to move bugs from reported to fixed and help your developers stay focused.

Defect_ID: Unique identification number for the defect.

Defect Description: Detailed description of the defect including information about the module in which defect was found.

Version: Version of the application in which defect was found.

Steps: Detailed steps along with screenshots with which the developer can reproduce the defects.

Date Raised: Date when the defect is raised

Reference: where in you Provide reference to the documents like . requirements, design, architecture or maybe even screenshots of the error to help understand the defect

Detected By: Name/ID of the tester who raised the defect

Status: Status of the defect , more on this later

Fixed by: Name/ID of the developer who fixed it

Date Closed: Date when the defect is closed

Severity: which describes the impact of the defect on the application

Priority: which is related to defect fixing urgency. Severity Priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively.