Defect Life Cycle

A defect life cycle is a process in which a defect goes through various phases. It happens during its entire lifetime or how a defect needs to be operated by its respective teams. It starts when a defect is encountered and ends when a defect is closed, after ensuring it’s not reproduced. A defect life cycle is related to the bug or defect found during the software testing.

As we have seen, a defect discovered in one phase may be identified in some other phase and can be fixed in some other phases of the software development.

A defect may run parallel to the software development phases.

A defect is identified by its states and status. And therefore we shall see all the states and statuses that are possible for a defect. Below are some of the states of a defect:

New: If we are saying a new defect it indicates that the defect is verified and it's open for now. And our developers or designers need to fix it as per its priority and severity respective to the defect category. Nothing had happened the same before as the defect itself is new.

Assigned: If we state a defect as assigned it means a status which is already given to the developers or designers team respective to defect category to take measures regarding its priority and severity, Assigned it itself is a status of the defect.

Open: Open is also a status given to a defect. Its respective designers or developers team is working on that defect. While a defect is open that always does not need to be under operation by the team, it may also be under observation by the team.

Fixed: Fixed is also a defect status itself, as a defect status is given as fixed then it means whatever the defect was according to its category. The respective designers or developers team has done their operations regarding it and it's been solved by them and is ok 

Pending Retest: This status is given for a defect as the defect been resolved or needed operations done from the end of developers or designers and their handover it to the tester team for verifying again against the issue which was given earlier to them but only when retest by the tester team is pending.

Verified: When the defect has been fixed by developers or designers according to the defect category then comes to the testing team for re-test and check the current status of the defect if it's really done or not done and to be confirmed by the team.

Reopen: If after verification the defect is not been solved by its respective designers or developers team then the tester team confirms the defect is still active and has not been resolved by the taken measures or operations then the defect status will be re-open.

Closed: When the required operations are done by the designers or developers team. And the change has fixed the issues which were created by the defect have been resolved. Verification of it is also done by the tester team and confirmed as solved by them. Then only the defect status can be closed.

Duplicate: The status of a defect can be duplicate if only the defect is already in the knowledge of the team and taken measures for that. And the same is happening on another page or module then the defect is considered a duplicate. And the same measures will be taken for it too which were taken for the previous same defect. But it will be under the same operations and re-test by respective teams.

Rejected: The status of a defect is rejected when the defect is not genuine. It needs to be verified by its respective designers and developers teams. It can not be fixed or no need to fix it then only with consulting with the tester team the defect can be addressed as rejected.

Deferred: The status of a defect can be deferred. It can not be fixed on the current phase of operations. Or the team will take necessary measures for that defect on a later phase of development or the new release of the software then only it can be stated as deferred.

Not A Bug: There can be a defect in the software. It may not need to be termed as a defect or bug. This defect may if it does not hamper the proper functionality of the software. In that case, the defect is termed as Not a Bug.

Below see the Defect Life Cycle:

From this above diagram, we come to know how we can treat a genuine defect. And which team at which time need to take measures against it. And from the diagram, it can be clearly inferred, how the defect's status is changing from time to time.

The defect is encountered for the first time. So, the status of the bug or defect is set to New. Then the defect is transferred to the team to analyze the defect.

Conclusion:

The team or the project manager may decide whether the defect is valid or not. If it is an invalid defect (defect which cannot be considered as a defect or is neither a bug) then the status for the defect is to Rejected. Or, if the defect is valid, then the next step is to assign a new status to the defect. Now in case, the defect is a similar one, then the defect is assigned as duplicate. But similar operations go on.