Bug Life Cycle

 Bug/Defect life cycle is a cycle 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. Defect life cycle is related to the bug found during testing.

Defect management process

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.

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 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, it’s 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: It’s 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 can 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 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.

Introduction to defect life cycle:

The defect life cycle can vary from organization to organization and from project to project based on several factors like organization policy, software development model used (like Agile, Iterative), project timelines, team structure etc.

This is important to know about the various states of a defect for understanding the life cycle of a defect. The main intention of performing a testing activity is to check if the product has any issues/errors. In terms of real scenarios, errors/mistakes/faults are all referred to as bugs/defects and hence we can say, that the main objective of doing a testing is to assure that the product is less prone to defects (no defects is an unrealistic situation).

Some organizations / projects / managers may adopt a simpler life cycle while others may use a more extensive life cycle as described below. Simpler implementations of the bug life cycle may not include all the states that have been shown below. This may not provide as much clarity into the defect / defect metrics, when the defects are being analyzed at a later date.

What Is Defect?

A Defect, in simple terms, is a flaw or an error in an application that is restricting the normal flow of an application by mismatching the expected behavior of an application with the actual one. The defect occurs when any mistake is made by a developer during the designing or building of an application and when this flaw is found by a tester, it is termed as a defect.

It is the responsibility of a tester to do a thorough testing of an application with an intention to find as many defects as possible to ensure that a quality product will reach the customer. It is important to understand about defect life cycle before moving to the workflow and different states of the defect.

A defect can be introduced in any phase of SLDC (Software Development Life Cycle) so it is very important that test team is involved from beginning of SDLC for detecting and removal of defects. The earliest the defect is detected and rectified, the minimal cost of quality will incur.

For Example: If the defect is identified in requirements phase then the cost of fixing it is just modifying the requirement whereas if the wrong requirement is designed and implemented in the code and found during the test execution phase then the cost to fix that defect will be very high as the fix needs to be done in requirement and then those changes need to propagate to design, development and testing again.

Hence, let’s take know more about Defect Life Cycle and understand the workflow of a defect and the different states of a defect.

Defect Life Cycle in Detail

A Defect life cycle, also known as a Bug life cycle, is a cycle of a defect from which it goes through covering the different states in its entire life. This starts as soon as any new defect is found by a tester and comes to an end when a tester closes that defect assuring that it won’t get reproduced again.

Defect Workflow:

It is now time to understand the actual workflow of a defect life cycle with the help of a simple diagram as shown below.

Defect States:

1) New: This is the first state of a defect in the defect life cycle. When any new defect is found, it falls in a ‘New’ state and validations and testing are performed on this defect in the later stages of the defect life cycle.

2) Assigned: In this stage, a newly created defect is assigned to the development team for working on the defect. This is assigned by the project lead or the manager of the testing team to a developer.

3) Open: Here, the developer starts the process of analyzing the defect and works on fixing it, if required. If the developer feels that the defect is not appropriate then it may get transferred to any of the below four states namely Duplicate, Deferred, Rejected or Not a Bug-based upon the specific reason.

4) Fixed: When the developer finishes the task of fixing a defect by making the required changes then he can mark the status of the defect as ‘Fixed’.

5) Pending Retest: After fixing the defect, the developer assigns the defect to the tester for retesting the defect at their end and till the tester works on retesting the defect, the state of the defect remains in ‘Pending Retest’.

6) Retest: At this point, the tester starts the task of working on the retesting of the defect to verify if the defect is fixed accurately by the developer as per the requirements or not.

7) Reopen: If any issue still persists in the defect then it will be assigned to the developer again for testing and the status of the defect gets changed to ‘Reopen’.

8) Verified: If the tester does not find any issue in the defect after being assigned to the developer for retesting and he feels that if the defect has been fixed accurately then the status of the defect gets assigned to ‘Verified’.

9) Closed: When the defect does not exist any longer then the tester changes the status of the defect to ‘Closed’.

FEW MORE:

• Rejected: If the defect is not considered as a genuine defect by the developer then it is marked as ‘Rejected’ by the developer.
• Duplicate: If the developer finds the defect as same as any other defect or if the concept of the defect matches with any other defect then the status of the defect is changed to ‘Duplicate’ by the developer.
• Deferred: If the developer feels that the defect is not of very important priority and it can get fixed in the next releases or so in such a case, he can change the status of the defect as ‘Deferred’.
• Not a Bug: If the defect does not have an impact on the functionality of the application then the status of the defect gets changed to ‘Not a Bug’

DETAILS:

1. A defect is in open state when the tester finds any variation in the test results during testing, peer tester reviews the defect report and a defect is opened.
2. Now the project team decides whether to fix the defect in that release or to postpone it for future release. If the defect is to be fixed, a developer is assigned the defect and defect moves to assigned state.
3. If the defect is to be fixed in later releases it is moved to deferred state.
4. Once the defect is assigned to the developer it is fixed by developer and moved to fixed state, after this an e-mail is generated by the defect tracking tool to the tester who reported the defect to verify the fix.
5. The tester verifies the fix and closes the defect, after this defect moves to closed state.
6. If the defect fix does not solve the issue reported by tester, tester re-opens the defect and defect moves to re-opened state. It is then approved for re-repair and again assigned to developer.
7. If the project team defers the defect it is moved to deferred state, after this project team decides when to fix the defect. It is re-opened in other development cycles and moved to re-opened state.
8. It is then assigned to developer to fix it.

On successful logging, the bug is reviewed by Development or Test manager. Test manager can set the bug status as Open, can Assign the bug to developer or bug may be deferred until next release.

Guidelines for Implementing Defect Life Cycle

There are some important guidelines which can be adopted before starting to work with defect life cycle.

Guidelines are as follows:

• It is very important that before starting to work on the defect life cycle, the whole team clearly understands the different states of a defect (discussed above).
• Defect Life Cycle should be properly documented to avoid any confusion in the future.
• Make sure that everyone who has been assigned any task related to defect life cycle should understand his/her responsibility very clearly for better results.
• Everyone who is changing the status of a defect should be properly aware of that status and should provide enough details about the status and the reason for putting that status so that everyone who is working on that defect can understand the reason of such a status of a defect very easily.
• Defect tracking tool should be handled with care to maintain the consistency among the defects and thus, in the workflow of the defect life cycle.

Conclusion

This is all about Defect Life Cycle. A Defect Life Cycle or Bug life cycle is a cycle which a defect goes through during its life span. Using the defect life cycle, the testers can identify a defect at any stage. While experimentally testing a case, you can seek a hidden defect. The defect life cycle plays a crucial role in bringing out defects from an operation.