How Does Defect/Bug Life Cycle Work in Software Testing?

Introduction to Defect Life Cycle

A defect life cycle is a process in which the reported defect goes through multiple stages in its life cycle. It starts as soon as a defect is found and closes when the tester is assured that it is fixed and not impacting any other functionality or areas of the software.

There are two major persons required in any Software Development process–

1. Software Developer – One who designs and implements the code.
2. Software Tester – One who tests the software, detects as many defects as possible in the system and reports them.

Defect States

When a defect is reported, it has to go through different states as mentioned below:

1. New

It is the very first state of the Defect Life Cycle. It occurs when a new defect is found and reported. In this, the tester makes a proper document by mentioning how to reproduce the defect.

2. Assigned

In this state, the bug is assigned to a particular developer who takes full responsibility for fixing the defect.

3. Open

When the developer starts working on the defect, its state change from assigned to open. The developer will go through the details of the tester’s information and will check if this is a valid defect or not. In this state, the defect can be moved to Duplicate, Deferred, or Rejected, based on analysis.

4. Fixed

When a defect is valid, the developer starts working on it. Once the developer fixes it by implementing the code changes and validates it on his end, the defect moves to the fixed state.

5. Pending Retest

Once the developer fixes the defect, he provides the latest code to the tester to retest the defect. The tester re-validates the defect and changes the defect status according to the results. It is changed to the ‘Pending Retest’ state when it is pending from the tester’s end.

6. Retest

It is the tester’s responsibility to retest the defect. If it is fixed, the tester closes the defect with proper evidence. If it is not fixed, the tester changes it to the re-open state. Once the defect is fixed, it moves to pending retest.

7. Re-Opened

Once a bug comes for a retest, the tester retests it. If the defect is still not fixed after the developer’s fix, the tester re-opens the defect and assigns it back to the developer for the fix. In this case, the defects must go through the whole life cycle again.

8. Deferred

The bug can be marked as deferred also. When a bug is marked as deferred, it means that it will be fixed in the next release. There might be many reasons to mark the defect as ‘Deferred’. It can be a low priority or a defect not affecting the software or functionality.

9. Duplicate

A defect can be marked as a duplicate if some other tester already reports the same defect. So, checking the reported defects before reporting any new defect is always advised to avoid duplicity.

10. Closed

When a defect comes for the retest, the tester retests the defect, and when he is confident that the defect is fixed properly, he marks the defect as close. It means the defect is retested, approved and closed, and it is not reproduced again.

11. Rejected

When the developer thinks the defect is not genuine, he marks the defect as rejected.

In addition, let’s discuss all the details required while reporting a defect.

Defect Data contains multiple details like –

• Problem Summary: It contains the summary of the defect.
• Defect Details: Defect Details include a detailed version of the defect.
• Steps to Reproduce: It includes all the details to reproduce the defect. 
• Frequency of Defect: The frequency of a defect suggests whether it is an Always Defect, Sometimes Defect, or Once Defect.
• Test Version: It conveys on which version the defect is found: Software or Build.
• Type of Defect: It includes the defect type, for example, if the defect is a functionality defect or UI defect.
• Severity: Defect severity means how severe the defect is. It is basically from an application point of view.
• Priority: Defect Priority means which defect should resolve first. It is basically from a user’s point of view.
• Name of the Tester: Name of the tester who reported the defect.
• Assignee: Developer who will resolve the defect.
• Resolution Version: In this software version, the defect gets fixed.
• Defect ID: A defect ID is assigned to the defect for future reference.

What Things Need to Keep in Mind While Implementing Defect Life Cycle

• Every team member should know about the defect life cycle and all the states in which the defect can be present.
• The defect should be properly documented. All steps to reproduce and details regarding the defect should be mentioned while reporting it.
• While changing the defect state, the person should be properly aware of what and why he is doing this and know properly about it. And a proper reason and evidence should be attached to the defect while updating the status of the defect.
• The defect tracking tool should be up to date.

Conclusion

The defect life cycle helps in finding the defect at different stages. It also helps the developers to fix the defect based on its severity and priority. You can easily track all the deferred defects by using this cycle which leaves very few chances of missing a defect.

By following the defect life cycle, Developers and Testers can be on the same page regarding the status of defects. There is no need to ask for defects individually because it can be used to track all the defects and status. The defect life cycle also allows the documentation of all the defects properly and ensures that the software or product is defect/bug-free.