Introduction
The defect life cycle is the path or states the defect might take during its life. The states of the defect are defined in the bug tracking tool used in the organization. The states may vary from one defect-tracking tool to another.
The standard states of the defect are listed below:
New
This state is when a defect is logged into the tracking tool for the first time. For example, when a tester logs a defect the state of the bug would be in a new state.
Assigned
This state is when the bug is assigned to a particular developer to work on the fix if the defect is valid.
Open
The developer has started working on fixing the defect. Open defects are valid defects that the developer agrees to fix.
Fixed
Developers fix the defect and mark the defect as fixed. Any changes done to the source code as part fix might be submitted as a change list to the bug.
Verified
The tester can verify the fixed defects and check if the defect is fixed and the functionality is working as expected.
Closed
Once the bug is verified by the tester he can close the bug. Closed defects are defects that are fixed and verified.
Reopen
Once the bug is fixed and the tester tries to verify. However, if the tester is not convinced the bug is fixed or the functionality is not working as expected. The bug would be reopened in the system so that the developer can revisit the fix for the bug.
Duplicate
Duplicate bugs are bugs that are logged in the system for the same issue. This might happen when several testers test the application simultaneously and find the same issue. To avoid duplicates the tester might search the tracking tool for existing bugs before logging the issue.
Not a bug
The developer marks the defect as not a bug if the issue reported by the tester is not valid.
Deferred
Deferred bugs are valid bugs but the target fix would be in the upcoming releases of the application. These are not urgent bugs that the developer team should fix in the current release.