Defect Management Process: How to Manage a Defect Effectively

Introduction to Defect Management Process:

The more focused process and testing will allow less buggy software in the market.

Defect Prevention is much more efficient and effective in reducing the number of defects and also is very cost effective to fix the defects found during the early stage of the software process. Most of the organizations conduct Defect Discovery, Defect Removal and then Process Improvement which is collectively known as a Defect Management Process. 

Goals of Defect Management Process (DMP)

Given below are the various goals of this process:

• Prevent the Defect
• Early Detection
• Minimize the impact
• Resolution of the Defect
• Process improvement

Before exploring the Defect Management Process, let us first understand what actually a defect or bug is?

Defect Management Life Cycle

When a system gives a different output other than the actual business requirement i.e. when there is a deviation from the actual or original business requirement then we can say that there is a defect in the system/software.

When the testing team executes the test cases, they come across a situation where the actual test result is different from the expected result. This variation is termed as a Defect.

Basically, a Software Defect is a condition which does not meet the software requirement. The defect is an error or a flaw which produces an unexpected or incorrect behavior in the system.

In order to handle the projects appropriately, you need to know how to deal with the development and release, but along with that you also need to know how to handle defects.

Just imagine, what will happen if the testing team reports the defects verbally and the development team also updates the status of defect verbally? The process will be more complicated as these defects include all defects like actually fixed and working as expected, fixed but still not working, rejected, postponed and the process goes on.

In the above case, as the numbers of defects get increased and communication is performed verbally, the situation will soon be very worst. In order to control and handle the defect effectively, you need proper Defect Life Cycle.

Defect Life Cycle ensures that the process is uniform and standardized. A defect attains different states in the life cycle. After a defect has been found, it goes through various stages during its lifetime and it is commonly known as Defect Life Cycle.

Generally, Defect life cycle starts from the stage when the defect is found or raised by the testing team and ends when a defect is closed either by ensuring that it’s not reproducible or rejected by a development team. The number of states that a defect goes through varies from project to project.

Further reading:

What is Defect/Bug Life Cycle in Software Testing? Defect Life Cycle Tutorial

Note: Below cycle slightly differs from organization to organization.

The below defect life cycle covers all possible status:

• Whenever the testing team finds a defect in the application, they raise the defect with the status as “NEW”.
• When a new defect is reviewed by a QA lead and if the defect is valid, then the status of the defect would be “Open” and it is ready to be assigned to the development team.
• When a QA lead assigns the defect to the corresponding developer, the status of the defect would be marked as “Assigned”. A developer should start analyzing and fixing the defect at this stage.
• When the developer feels that the defect is not genuine or valid, then the developer rejects the defect. The status of the defect is marked as “Rejected” and assigned back to the testing team.
• If the defect logged is repeated twice or both the defects reported have similar results and steps to reproduce, then one defect status is changed to “Duplicate”.
• If there are some issues or hurdles in the current release for fixing a particular defect, then the defect would be taken in the upcoming releases instead of the current release and then it is marked as “Deferred” or “Postponed”.
• When a developer is not able to reproduce the defect by the steps mentioned in “Steps to Reproduce” by the testing team then the developer can mark the defect as “Not Reproducible”. In this stage, the testing team should provide detailed reproducing steps to a developer.
• If the developer is not clear about the steps to reproduce provided by a QA to reproduce the defect, then he/she can mark it as “Need more information”. In this case, the testing team needs to provide the required details to the development team.
• If a defect is already known and currently present in the production environment then the defect is marked as “Known defect”.
• When a developer makes the necessary changes, then the defect is marked as “Fixed”.
• The developer now passes the defect to the testing team to verify, so the developer changes the status as “Ready for Retest”.
• If the defect has no further issues and it is properly verified, then the tester marks the defect as “Closed”.
• While retesting the defect if the tester found that, the defect is still reproducible or partially fixed then the defect would be marked as “Reopened”. Now the developer has to look again into this defect.

A well planned and controlled Defect Life Cycle gives the total number of defects found in a release or in all releases. This standardized process gives a clear picture of how the code was written, how properly the testing has been carried out, how the defect or software has been released, etc. This will reduce the number of defects in production by finding the defects in the testing phase itself.

Defect Management Process

Defect management process is explained below in detail.

#1) Defect Prevention:

Defect Prevention is the best method to eliminate the defects in the early stage of testing instead of finding the defects in the later stage and then fixing it. This method is also cost effective as the cost required for fixing the defects found in the early stages of testing is very low.

However, it is not possible to remove all the defects but at least you can minimize the impact of the defect and cost to fix the same.

The major steps involved in Defect Prevention are as follow:

• Identify Critical Risk: Identify the critical risks in the system which will impact more if occurred during testing or in the later stage.
• Estimate Expected Impact: For each critical risk, calculate how much would be the financial impact if the risk actually encountered.
• Minimize expected impact: Once you identify all critical risks, take the topmost risks which may be harmful to the system if encountered and try to minimize or eliminate the risk. For risks which cannot be eliminated, it reduces the probability of occurrence and its financial impact.

#2) Deliverable Baseline:

When a deliverable (system, product or document) reaches its pre-defined milestone then you can say a deliverable is a baseline. In this process, the product or the deliverable moves from one stage to another and as the deliverable moves from one stage to another, the existing defects in the system also gets carried forward to the next milestone or stage.

For Example, consider a scenario of coding, unit testing and then system testing. If a developer performs coding and unit testing then system testing is carried out by the testing team. Here coding and Unit Testing is one milestone and System Testing is another milestone.

So during unit testing, if the developer finds some issues then it is not called as a defect as these issues are identified before the meeting of the milestone deadline. Once the coding and unit testing have been completed, the developer hand-overs the code for system testing and then you can say that the code is “baselined” and ready for next milestone, here, in this case, it is “system testing”.

Now, if the issues are identified during testing then it is called as the defect as it is identified after the completion of the earlier milestone i.e. coding and unit testing.

Basically, the deliverables are baselined when the changes in the deliverables are finalized and all possible defects are identified and fixed. Then the same deliverable passes on to the next group who will work on it.

#3) Defect Discovery:

It is almost impossible to remove all the defects from the system and make a system as a defect-free one. But you can identify the defects early before they become costlier to the project. We can say that the defect discovered means it is formally brought to the attention of the development team and after analysis of that the defect development team also accepted it as a defect.

Steps involved in Defect Discovery are as follows:

• Find a Defect: Identify defects before they become a major problem to the system.
• Report Defect: As soon as the testing team finds a defect, their responsibility is to make the development team aware that there is an issue identified which needs to be analyzed and fixed.
• Acknowledge Defect: Once the testing team assigns the defect to the development team, its the development team’s responsibility to acknowledge the defect and continue further to fix it if it is a valid defect.

#4) Defect Resolution:

In the above process, the testing team has identified the defect and reported to the development team. Now here the development team needs to proceed for the resolution of the defect.

The steps involved in the defect resolution are as follows:

• Prioritize the risk: Development team analyzes the defect and prioritizes the fixing of the defect. If a defect has more impact on the system then they make the fixing of the defect on a high priority.
• Fix the defect: Based on the priority, the development team fixes the defect, higher priority defects are resolved first and lower priority defects are fixed at the end.
• Report the Resolution: Its the development team’s responsibility to ensure that the testing team is aware when the defects are going for a fix and how the defect has been fixed i.e. by changing one of the configuration files or making some code changes. This will be helpful for the testing team to understand the cause of the defect.

#5) Process Improvement:

Though in the defect resolution process the defects are prioritized and fixed, from a process perspective, it does not mean that lower priority defects are not important and are not impacting much to the system. From process improvement point of view, all defects identified are same as a critical defect.

Even these minor defects give an opportunity to learn how to improve the process and prevent the occurrences of any defect which may impact system failure in the future. Identification of a defect having a lower impact on the system may not be a big deal but the occurrences of such defect in the system itself is a big deal.

For process improvement, everyone in the project needs to look back and check from where the defect was originated. Based on that you can make changes in the validation process, base-lining document, review process which may catch the defects early in the process which are less expensive.

Conclusion

The Defect Management Process should be followed during the overall software development process and not only for specific testing or development activities.

If a defect found in the testing phase then a question can be raised that if the defect is caught in this phase then what about the other defects that are alive in the system which may cause system failure if it occurs and is not yet discovered.

So all processes like review process, static testing, inspection, etc., need to strengthen and everyone in the project should be serious about the process and contribute wherever necessary. Senior management in the organization should also understand and support the defect management process.

Testing approaches, review process etc., should choose based on the project objective or organizational process.

Hope this informative article on Defect Management Process is of immense help to you.