Defect Life Cycle

Defect/Bug Life Cycle in Software Testing

Life Cycle of a Defect or a Bug In the context of software testing, the term “life cycle” refers to the sequence of stages that a software defect or error passes through over the course of its existence. The goal of the Defect life cycle is to facilitate easy coordination and communication among the various assignees regarding the current status of the defect as it changes, as well as to make the process of fixing defects more methodical and effective.

Defect Status

Status of the Error or Bug The current state that a bug or defect is in during its journey through the defect life cycle is referred to as the defect’s status. The purpose of defect status is to accurately convey the current state or progress of a bug or defect so that the actual progression of the defect life cycle can be better tracked and understood.

It varies from project to project how many different states a defect must pass through before being fixed. The below state diagram, which covers all possible ones, is for the lifecycle.

When a new defect is logged and posted for the first time, the term “new” refers to this event. The status of NEW has been given to it.
Assigned: Once the bug has been posted by the tester, the lead tester will review the bug, give their approval, and then assign the bug to the development team.
Open: The programmer will immediately begin analysing the problem and working to fix it.
Fixed: A bug’s status can be set to “Fixed” once a developer has made all of the necessary code changes and verified that those changes have been made.
Pending retest: Once the issue has been resolved, the developer will provide the tester with a specific code for the purpose of retesting the code. Because the software testing has not yet been completed from the end of the testers, the status that has been assigned is “pending retest.”
Retest: The tester will now perform another round of testing on the code to determine whether or not the developer has successfully fixed the issue, at which point the status will be changed to “Re-test.”
Defect Life Cycle Verified indicates that the bug has been retested by the tester after the developer has applied a fix to it. The bug is considered to be fixed and the status given is “verified” if it can be determined that the software does not contain any errors.
Reopen: If the bug still exists after the developer has applied the fix for the bug, the tester will change the status to “reopened” to reflect the situation. Once more, the insect goes through the various stages of its life cycle.
Closed: The status of the bug is changed to “Closed” when the tester confirms that it is no longer present.
The status of the defect is changed to “duplicate” whenever it is determined that the defect has been repeated twice or that the defect corresponds to the same concept as the bug.
Rejected If the developer believes that the defect is not an actual flaw in the product, they will change the defect’s status to “rejected.”
The status of “Deferred” is given to bugs that meet the following criteria: the bug in question is not considered to be of the highest importance, and its resolution is anticipated to coincide with the subsequent release.
“Not a bug” is the status that is given to a bug when it is determined that the functionality of the application is not compromised in any way by the issue

Defect Life Cycle Explained

An Explanation of the Defect Life Cycle
The Life Cycle of a Defect, also Known as the Life Cycle of a Bug – Important Information!
The flaw is discovered by the tester.
The status of the defect has been assigned as New.
The Project Manager is informed of a defect and asked to investigate it.
The Project Manager is responsible for determining whether a defect actually exists.
In this instance, the defect does not meet the criteria, so the status is changed to “Rejected.”
Therefore, the status is changed to rejected by the project manager. If the defect is not rejected, the next step is to determine whether or not it falls within the scope of the project. Let’s say that we have another function for the same application, and that function is the email functionality. You discover a problem with it. When however, such flaws are given a postponed or deferred status, they are not considered to be a part of the currently available release.
The manager then looks into whether or not an earlier report of an identical defect was made. If the answer is yes, the defect is given the status of duplicate.
If the answer is “no,” the problem is given to the developer, who then begins fixing the code. In this phase of the process, the defect will be given a status of “in- progress.”
After the bug in the code has been fixed. When a defect has been resolved, it is given the status fixed.
The code will then undergo a second round of testing by the tester. In the event that the Test Case is successful, the issue has been resolved. In the event that the test cases continue to fail, the issue will be reopened and given back to the developer.
Consider the following scenario: during the first release of Flight Reservation, a flaw was discovered in the Fax order. This flaw was fixed, and the status of the issue was changed to closed. During the second release of the upgraded software, the same bug was discovered once more. In these kinds of circumstances, a defect that had been closed will be reopened.
That wraps up the Life Cycle of Bugs.

The significance of each stage in the life cycle of a bug, also known as a defect, is demonstrated in this training video through the use of a specific example.