Defect Management Process

1.   Introduction

Defect management is crucial to closing the loop between requirements, implementation and verification and validation. The cost of finding and correcting defects represents one of the most expensive software development activities. For the foreseeable future, it will not be possible to eliminate defects.  While defects may be inevitable, we can minimize their number and impact on our projects. To do this development teams need to implement a defect management process that focuses on preventing defects, catching defects as early in the process as possible, and minimizing the impact of defects.

1.1       Definition

The process of recognizing, investigating, taking action and disposing of defects. It involves recording defects, classifying them and identifying the impact.

Defect: Defect is a deficiency in a software product that causes it to perform unexpectedly.

1.2       Goals of Defect Management:

Following are the goals of defect management:

·         Prevent the defect.

·         Early Detection.

·         Minimize the impact.

·         Risk driven process

·         Continuous effort to improve the process.

     2.   Defect Management Process

The defect management process contains the following elements:

·         Defect Prevention

·         Deliverable Baseline

·         Defect Discovery

·         Defect Analysis & Prioritization

·         Defect Resolution

·         Process Improvement

 Defect Prevention: Defect Prevention is a process of improving quality and productivity by preventing the injection of defects.

Defect prevention should begin with an assessment of the critical risks associated with the system.  Getting the critical risks defined allows people to know the types of defects that are most likely to occur and the ones that can have the greatest system impact.  Strategies can then be developed to prevent them.  The major steps for defect prevention are as follows:

·         Identify Critical Risks

·         Estimate Expected Impact

·         Minimize Expected Impact

Deliverable Baseline: When a product reaches a predefined milestone in its development then it is baselined. This milestone involves transferring the product from one stage of development to the next. A product should be considered baselined when developer passes it on for integration testing.

The concept of baselining is important because it requires an organization to decide both the level of formality that is appropriate, and the point in the process when the formality takes effect.  In general, a deliverable should be baselined when changes to the deliverable, or defects in the deliverable, can have an impact on deliverables other people are working on.

Deliverable baseline involves the following activities:

·         Identify key deliverables: Select those deliverables that will be baselined and the point within the development process where the deliverable will be baselined.

·         Define standards for each deliverable: Set the requirements for each deliverable and the criteria that must be met before the deliverable can be baselined.

Defect Discovery: A defect is said to be discovered when it is brought to the attention of the developer and is acknowledged to be a valid one. The defect tracking software must be simple enough so that people will use it, but ensure that the minimum necessary information is captured. The information captured here should be enough to reproduce the defect and allow development to determine root cause and impact.

The defect discovery involves the following steps:

·         Find Defect

·         Report Defect

·         Acknowledge Defect

Defect Analysis & Prioritization: The development team determines if the defect report corresponds to an actual defect, if the defect has already been reported, and what the impact and priority of the defect is. Prioritization and scheduling of the defect resolution is often part of the overall change management process for the software development organization.

Defect Resolution: Here the development team determines the root cause; implements the changes needed to fix the defect, and documents the details of the resolution in the defect management software, including suggestions on how to verify the defect is fixed.

Process Improvement: Identification and analysis of the process in which a defect originated to identify ways to improve the process to prevent future occurrences of similar defects.  Also the validation process that should have identified the defect earlier is analyzed to determine ways to strengthen that process.

      3.    Defect life cycle

Defect/bug life cycle is a process which a defect goes through during its lifetime. It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced.

 New State: When the defect is found and submitted by the tester, New status is automatically assigned to it.

Open: If the defect is accepted for repair, Test lead or QA change the status to Open and assign it to development team.

Rejected: A Test lead or QA reviews the defect and decides whether or not to repair the defect. If the defect is refused, Rejected status is assigned to the defect.

Assigned: A defect has been verified and by the development team is now Assigned to the developers for fixing.

Fixed: The development teams repairs the defect and change its status to fixed. They then assign the defect back to quality assurance or project manager.

Retest: After the defect is fixed, the quality assurance or project manager change the status of defect to Retest and assigns the defect to tester.

Reopen: The testers retest the defect and see if it has been repaired or not. If the bug still exists, it is again changed to Reopen status. The defect the again passes through fixed, and retest status until it has been fixed.

Closed: If the defect is found repaired after retest, the quality assurance or project manager changes the defect to Closed.

Deferred: The development team reviews the defect and decides to fix the defect in current fix or in some other fix release. If defect is decided not to be fixed in current release, deferred status is assigned to it.

     4.   Severity & Priority

There are two key things in the defect of the software testing. They are:

·         Severity

·         Priority

1)    Severity: It is the extent to which the defect can affect the software. In other words it defines the impact that a given defect has on the system.

Severity can be of following types:

Critical: The defect that results in the termination of the complete system or one or more component of the system and causes extensive corruption of the data. The failed function is unusable and there is no acceptable alternative method to achieve the required results then the severity will be stated as critical.

Major: The defect that results in the termination of the complete system or one or more component of the system and causes extensive corruption of the data. The failed function is unusable but there exists an acceptable alternative method to achieve the required results then the severity will be stated as major.

Moderate: The defect that does not result in the termination, but causes the system to produce incorrect, incomplete or inconsistent results then the severity will be stated as moderate.

Minor: The defect that does not result in the termination and does not damage the usability of the system and the desired results can be easily obtained by working around the defects then the severity is stated as minor.

Cosmetic: The defect that is related to the enhancement of the system where the changes are related to the look and field of the application then the severity is stated as cosmetic.

2)  Priority: Priority defines the order in which we should resolve a defect. Should   we fix it now, or can it wait? This priority status is set by the tester to the developer mentioning the time frame to fix the defect. If high priority is mentioned then the developer has to fix it at the earliest. The priority status is set based on the customer requirements.

 Priority can be of following types:

Low: The defect is an irritant which should be repaired, but repair can be deferred until after more serious defect has been fixed.

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

High: The defect must be resolved as soon as possible because the defect is affecting the application or the product severely. The system cannot be used until the repair has been done.

Few very important scenarios related to the severity and priority which are asked during the interview:

High Priority & High Severity: An error which occurs on the basic functionality of the application and will not allow the user to use the system. (Eg. A site maintaining the student details, on saving record if it, doesn’t allow to save the record then this is high priority and high severity bug.)

High Priority & Low Severity: The spelling mistakes that happens on the cover page or heading or title of an application.

High Severity & Low Priority: An error which occurs on the functionality of the application (for which there is no workaround) and will not allow the user to use the system but on click of link which is rarely used by the end user.

Low Priority and Low Severity: Any cosmetic or spelling issues which is within a paragraph or in the report (Not on cover page, heading, title).

     5.   Defect Management Tools

A tool that facilitates the recording and status tracking of defects and changes. They often have workflow-oriented facilities to track and control the allocation, correction and re-testing of defects and provide reporting facilities.

Following are the core features of a defect management tool:

·         Provides a centralized repository for tracking defects across projects.

·         Provides automated notifications of resource assignments.

·         Ability to define defect resolution status in order to map back to your defect management process.

·         Ability to provide management reporting, like the number of open defects grouped by various criteria such as open defects by project, severity, and priority.

     6.    Conclusion:

A defect management system is made up of a combination of defect management tools and a defect management process.

In addition, the effectiveness of a defect management system is influenced by the organizational culture it operates within. For most environments, it makes sense to utilize tools and processes that focus on the speed of identifying, tracking, and resolving defects. This provides the basis for understanding root cases and making appropriate process improvements. If the culture of the team or organization considers defects as negative, people spend more time trying to avoid defects and also are less likely to report a defect when encountered. This can lead to some defects being identified later in the process, when they are harder and more costly to fix.