The path through which a defect goes through during the software development process is normally stated as a Defect life cycle. It begins when a defect is found during testing and ends when the defect is closed or fixed, after making sure that it cannot be reintroduced into the system. Defect life cycle is completely based on the bugs and defects that are found during the software testing process.

The defect life cycle of a bug detected during software testing can vary from organization to organization and from project to project depending on several factors such as organization policy, software development model adopted, project timelines, and team structure.

In any case, the defect life cycle mainly depends on the bug life cycle model adopted. Now, some software developing companies may adopt simpler life cycle while other companies may use more extensive bug life cycle, all depending on how big or small the project and the bug detected is.

There are different states of a bug in a life cycle. It is possible to represent a bug life cycle through the figure given below.

From the figure above, it can be clearly seen that a bug detected goes through several steps in its life cycle. These steps are normally known as the status of the bug. Each status of a bug life cycle is explained further in detail below.

New – When a bug is defected for the first time and is recorded and logged for the first time, its state is known as New.

Assigned – After the bug is logged and posted, it needs approval from the lead tester to make sure whether the bug is genuine or not. If the bug is found to be genuine, it is assigned to corresponding developer or developer team. This state is known as Assigned.

Open – This status refers to the life cycle step in which the developer has started analyzing and working on how to fix the bug permanently and is known as Open state.

Fixed – After working and analyzing an Open defect, the developer makes necessary code changes and makes sure that the changes made completely fixes the bug and then passes it on to the testing team. This life cycle state in which the developer fixes the bug is known as Fixed state.

Pending Retest – After the defect is fixed by the developer and is passed on to the tester, the tester needs to retest the fixed code to make sure it works just as expected. Here, the testing is pending from the tester’s side. This state of bug life cycle is known as Pending Retest.

Retest – In this state, the pending code that needs to be retested is tested to make sure that the changes made by the developer fixes the defect or not. This state is known as Retest state.

Verified – The tester checks again the code changes made by the developer to fix the bug. If the bug is completely fixed without any problems, then the tester approves it and changes the status of the bug to Verified.

Reopen – However, if the bug exists even after it was fixed by the developer the tester changes the status of the bug to Reopen. From here on, the bug goes through the entire life cycle again.

Closed – In case if the bug is fixed by the developer, the tester tests it again. If the tester feels that the bug is completely fixed, then the status of the bug is changed to Closed state, which means that the bug is fixed, tested and approved.

Duplicate – If the bug appears twice in the software under the same name and concept, then one of the bug’s state is changed to Duplicate.

Rejected – If the developer feels that the bug reported by the tester is not genuine, then he simply rejects the bug. In this scenario, the state of the bug is changed to Rejected.

Deferred – Sometimes, a bug is not immediately fixed and is scheduled to fix in the next release. Such bugs are known to be in a Deferred state. There can be many reasons to why a bug is being deferred, such as low priority of the bug, lack of time for the release or maybe because the bug may not have any major effects on the working software.

Not a Bug – Here, if there is a bug reported and after fixing that bug, there seems to be no change in the functionality of the application, then that bug is stated as ‘Not a Bug’. For instance, reporting a change in color and design of the application is clearly ‘Not a Bug’.