Defect Management Process in Software Testing

In this tutorial, we will study the Defect Management Process of software testing. When a defect occurs in a system, it requires a defect management process for identifying, tracking, and resolving the bugs and defects more efficiently. Before moving forward with to defect management process, let's recall what a defect is.

What is a defect?

As discussed in previous tutorials, a defect is a destructive element for all software and applications. In other words, a bug is introduced as a difference between the client's requirements and the developed software or application. It is also referred to as an error or flaw in the system that deviates the system from performing its expected functions and work. Other terms used for defects are bugs, issues, faults, problems, incidents, etc.

Bugs or defects are also acknowledged as a result or consequences of programming or coding errors and mistakes. It is identified by the testing team while testing the system to ensure that the system should meet the quality standard as per the client. A defect is identified when a tester is not getting the desired results while executing the test cases, and there might be some issues in the application under test due to which bugs and defects are occurring in the system. Once the defects are found, they are moved or assigned to developers for a fix.

There could be multiple reasons behind the occurrence of defects and bugs in the system. Some of them are errors in coding and logic (such as missed code, wrong code, or code overlapping), inaccurate input data, wrong implementation of the internal structure and design of the application, etc.

What is Defect Management Process (DMP)?

A Defect Management Process (DMP) is a procedure or cycle for managing defects or bugs that occur in a software or system. In other words, it is a structured process of handling defects that starts with identifying bugs and issues and ends with resolving those issues and bugs in the system. As we all know, 100% defect-free software or application is hard to find. However, we can reduce the number of defects by identifying and fixing them at the right time with the help of the defect management process.

It plays a crucial role in software testing when a tester founds a bug or defect in the system. The most important task for the entire project team is to manage that defect from beginning to end efficiently. This activity is equally important for testing and development teams and the project managers and leads. If any of them fails to manage the defect or fault, it may lead to serious consequences or system failures. To avoid such situations, a defect management process is used to manage the defects, faults, and bugs of the system completely and systematically.

The objective of DMP is to handle the defect by identifying bugs as early as possible, reducing the impact of bugs on the application, fixing defects within the time range, and stopping defects.

The defect management process contains various stages, which are mentioned below:

1. Preventing Defects
2. Baseline Delivery
3. Discovering Defects
4. Resolving Defects
5. Improving Processes
6. Managing Reports

Before discussing the stages of the defect management process in detail, let us quickly learn the goals of the defect management process.

Goals of Defect Management Process

Following are the goals and objectives of the defect management process:

1. The primary focus of DMP is to prevent defects and faults from the system by early detection of defects in the early stages.
2. It also helps manage defects, faults, and incidents throughout the software development and testing process.
3. DMP is also used for reducing the impact and efforts on the affected module and other modules linked to it.
4. The defect management process also helps in improving the process, management, and implementation of the software.
5. The defect management process is also helpful in fixing and resolving the defects and issues in the system.
6. Many organizations use DMP for providing the information and date for the defect release.
7. It keeps track of the progress report and status of the reported defects.
8. Operational support is provided by the defect management system for resolving, fixing, and retesting the defects found in the software or application.
9. When a defect is identified, Defect Management Process completely handles the defect with all required information and finds the root cause of the defect to prevent it in the future state.

Stages of Defect Management Process

As we have discussed above, there are mainly six stages of the Defect Management Process. Let us discuss each stage one by one in detail.

Preventing Defects or Defect Prevention

Defect Prevention is the initial stage of the Defect Management Process. Without any doubt, it is the best approach to eliminate all possible defects from the system in the early phases of testing. It is mainly used to implement strategies, techniques, and methodologies for preventing defects. It is an essential activity to detect and remove a possible number of defects in the early phases instead of identifying them in the latter stages, as the effect and impact of the defects would be minimized, and there are fewer chances of system failure. Also, early detection and prevention of defects are cost-effective compared to fixing defects in later stages.

The purpose of the defect prevention stage is to quickly eliminates all the defects from the system as early as possible. However, this is an impossible task because 100% of bugs and defects cannot be identified and prevented. With the collaboration of developers and testers, a possible number of defects can be prevented, and the risk associated with them can be reduced. Therefore, finding and implementing the best strategies and techniques for preventing defects is crucial.

Following are the major steps for the defect prevention stage:

1. Identifying Critical Risks – In this step, we will identify the risks associated with the defects and bugs that will badly affect the system if it remains unfixed or comes up in the later stages. These defects can endanger the performance, construction, operation, and successful delivery of the system.
2. Estimating Expected Impact – In this step, we will determine the estimated financial cost or impact on the organization when a critical risk is encountered in the system.
3. Minimizing Expected Impact – In this step, we will try to minimize the impact a critical risk makes on the system. When a system encounters a critical risk, we will try to identify its impact and effectiveness on the system and prioritize eliminating that risk. If the risk is not eliminated, the possibility of its existence and impact will be reduced.

Baseline Delivery

Baseline Delivery is the second stage of the Defect Management Process. When a product or system achieves a pre-defined milestone or benchmark, it is said to be a baseline delivery of the product. A pre-defined milestone is the expected working of the system for which it has been developed. The product achieves a milestone when it is moved from one development stage or phase to another. When it reaches the higher milestones, the impact of the defects will be riskier and more massive on the system, and the cost of fixing the defect will be more. Sometimes, when a system is moved to the next milestone, it contains defects carried forward to the next milestone.

Let us understand baseline delivery with the help of an example. Suppose a product is under development, and the developers have been assigned programming and unit testing of the system. And the testing team is responsible for the smoke and sanity testing of the system. In this case, programming and unit testing is one milestone, and smoke and sanity testing is another module for the product. Therefore, when a developer finds a bug or issue in the coding or unit testing, it is not referred to as a defect because the issue occurred before completing the milestone. Once the programming and unit testing is completed and the product is moved to the testing team, the code is said to be Baselined and achieved one milestone. When the product is moved to the next milestone, and if testers find any issue while performing smoke and sanity testing, the issue is reported as a defect as it is identified after the completion of the first milestone. Hence, in this stage, the deliverables are baselined based on the modifications to the deliverables and defect fixing is done in the product.

The Baseline Delivery steps include the below-mentioned activities:

1. Finding key deliverables – In this step, we will identify all possible deliverables based on the requirements.
2. Setting up standards for deliverables – In this step, prerequisites are defined for all the deliverables identified above. An exit criterion is also defined for the deliverables.

Discovering Defects or Defect Discovery

It is the third stage of the Defect Management Process. At this stage, the team is more focused on the early discovery of all possible defects. Defects are said to be discovered only when a developer approves and accept them as valid defect. After the approval of a developer, the defect is documented.

As we all know, it is an impossible task to discover and fix all the defects of the system, but identifying most of the defects in the early stage will benefit the organization as the cost of fixing defects in later, or higher phases of the development cycle are more expensive compared to early phases.

The main purpose of this activity is to defect all the errors, problems, and defects that come up frequently in the system and to minimize the conflicts over the defect validity and failures due to defects and errors in the system.

Following are the steps involved in the Defect Discovery stage:

1. Defect Identification – In this step, the discovery and identification of defects and bugs are made before they harm or damage the system.
2. Defect Reporting – After discovering the defects, testers report the defects on the defect tracking tool and assign them to the developer for a fix. Developers analyze the defects and work on resolving them.
3. Defect Acknowledgement – Once the defect is assigned to a developer, it is the responsibility of the developer to acknowledge the defect if it is a valid one and start working on fixing the defect.

Resolving Defects or Defect Resolution

It is the fourth stage of the Defect Management Process. In the previous step, the testing team discovered and reported the defects to the development team. Once the defect is reported and assigned to the developer, the next step or stage of the defect management process is Defect Resolution.

After completing the Defect Discovery stage, we begin with the Defect resolution step. It is a step-by-step procedure for fixing or resolving the defects of the system. The process starts with analyzing the defect to find the root cause. After that, the developer starts with the resolution of the defect based on the defect priority.

The entire defect resolution process has been tracked by a defect tracking tool so that both developers and testers must be aware of the defect status. Once the defect is resolved, a bug report or defect report is prepared as evidence.

Following are the steps included in the Defect Resolution stage:

1. Prioritizing the defect – In this step, developers identify and prioritize the defect based on the impact and risk on the system. The higher priority defects are fixed before the low priority ones.
2. Defect fixing – After prioritizing the defects, developers begin with the fixing of the defect. Based on the defect priority and order of importance, defects are selected and fixed.
3. Reporting the resolution – In this step, developers keep the other teams and managers informed on the defect resolution. Once the defect is fixed, a defect resolution report is created and sent to the testing team so that all other teams are aware of the defect resolution and the root cause.

Improving Process or Process Improvement

It is the fifth stage of the Defect Management Process. Once the higher priority defects are fixed, the developers will focus on the lower priority defects and fix them. Lower priority defects are also harmful to the system and should be fixed, although they create less impact on the system than high priority defects. Sometimes, low priority or minor issues remain untouched in the system and doesn't affect the functionality and performance of the system. But it is the developer's and tester's responsibility to identify and fix all the defects.

Here comes the opportunity to enhance or improve the process by reviewing the activities, tasks, documents, and mistakes and learning from them for future projects and processes. Each person from the team should analyze the origin of the defect or root cause so that it can be avoided in the next releases and projects.

Managing Reports

It is the sixth and last stage of the Defect Management Process. After completing all the stages of the defect management process, the team should also keep an eye on the report management. Report management is the most critical element or step of the defect management process. It is equally important to find a defect and correctly communicate it to the development team, project managers, and senior managers and sometimes the product team (Business Analyst) are also involved.

When a defect is found by a tester, the defect management process starts with the identified defect. All information related to that defect is collected and documented for the number of reasons listed below:

• For reporting the defect status to the concerned team.
• For providing strategic information to the management such as defect occurrence, trends, problems systems, etc.
• Updating the metrics and information to the project team helps them make correct decisions, such as error-prone areas, the risk associated with it, the need for more testing, etc.
• To provide information to the project managers and testing team related to the cost and due dates of the defects.
• It also helps the team improve the process by reviewing and learning from the current activities and mistakes.

Defect Workflow and States

In software testing, there are different stages and specific workflow for managing defects. When the testers find a defect in the system, particular actions are taken to manage and resolve the defects at different stages. Defect management is the second most important task for a developer throughout the Defect Life Cycle.

During the entire Defect Life Cycle, a defect and its report are owned by a particular owner, be it a developer or tester, and one person will own the defect and its report at each stage or state of the defect life cycle. The person owning the defect will be responsible for performing the defect-related tasks at that particular stage. Once the tasks are completed at that particular stage, the defect and its report will be moved to the next stage and assigned to the next responsible owner of that stage. When the defect and its report reach the terminal or last stage of the defect life cycle, the defect and report will not have an owner in these particular states as no further actions are required on the defect. The reasons for not having an owner are mentioned below:

• When the developer finds that the defect is NOT A BUG, the defect status will be updated as Invalid, and no further actions are required. The defect report gets cancelled in such cases.
• When the defect is of low priority or cannot be fixed in the current release, the defect status and report are updated as DEFERRED, and the defect fix is postponed to the next release.
• When the defect is not identified or detected, the defect status and report will be marked as NOT REPRODUCIBLE.
• When the defect reaches the last stage of the defect life cycle, that is, a CLOSED state, the defect is already fixed, tested, verified and ready to close.

There are mainly three states for managing the defects, which are mentioned below:

• Initial State
• Returned State
• Confirmed State

Let us discuss each state thoroughly.

Initial State

It is the initial or first state for managing defects. It is also known as Open or New state. In this state, the testing team is responsible for gathering data and information required to fix the defects. If the collected information is incorrect or incomplete, it will impact the resolution and fixing of the defects. Hence, it is necessary to gather all information correctly.

Returned State

It is the second state for managing defects and is mainly referred to as the Rejected or Clarification state. In this state, the developer or the defect report receiver rejects the report due to incorrect or incomplete information and asks for more information regarding that defect. It will happen when the information gathering is not correctly done in the initial or previous state. Once the developer rejects the report, the tester (creator of the report) either provides the additional information or accepts the rejected report.

Confirmed State

It is the last state of defect management which is also known as the Verified or Resolved State. In this state, the testers perform confirmation testing to ensure that the defect is fixed and the module is working as per the expectations. It is done by repeating the testing steps through which the defect was found earlier. If the confirmation testing is successful and the defect is resolved, the tester closes the defect report. Otherwise, the defect status and report are marked as Re-opened and assigned back to the developer for a fix.

Advantages of Defect Management Process

Following are the advantages of the Defect Management Process:

• It helps in improving the quality of the product by reducing the defect count and delivering a high-quality product with zero possible defects. It helps in achieving customer satisfaction and customer loyalty.
• It allows the use of automation tools for defect tracking, as defect tracking is one of the crucial features of the defect management process. To track all possible defects, we need automation tools for early detection and tracking. Therefore, DMP allows us to use various tools available in the market for tracking different bugs and defects, such as software tools for tracking non-technical issues, user-facing tools for tracking production-related defects and issues, and internal automated tools for developers to track defects.
• It also helps in reducing the cost of the overall testing process as it works on the early detection of the defects, which reduces the cost as well as the risk associated with it.
• It strictly focuses on the detection and resolution of defects. DMP ensures that all the possible defects should be detected, tracked, and resolved as quickly as possible.
• It also provides valuable defect metrics along with the accessibility of automation tools. The defect metrics help the testing team in successful reporting and continuous improvements.

Disadvantages of Defect Management Process

Following are the advantages of the Defect Management Process:

• The main drawback of DMP is that it is a time-consuming procedure as we have to discover and track all possible bugs in the system. Sometimes, this activity may exceed the cost estimation of testing or the overall project.
• If the DMP is not performed correctly and efficiently, it may lead to disputes with customers and clients, loss of customers and revenue, and damage to brand reputation.
• If DMP is not appropriately performed at the early stages of testing, it may lead to huge damage and risk to the entire system and can cause a system failure.

Hence, to avoid such a situation, we should properly perform the defect management process throughout the testing phase.