Human language:
A defect life cycle - is a path that a defect follows from its inception to resolution.
It starts when the defect is found and ends when a defect is closed, after ensuring it’s not reproduced. The defect life cycle can vary from organization to organization and also from project to project based on several factors like organization policy, team structure, software development model used, project timelines, etc. Some projects may use a simpler life cycle, while others may use a more extensive life cycle.
A defect life cycle consists of phases. At each phase, an issue found in the software is assigned a specific defect status by either a QA engineer or a development team, which indicates the state of a bug at the moment and who is currently working on it.
The Life cycle of the bug consists of, but is not limited to, the following statuses:
New
This is the first state of a defect in the Defect Life Cycle. This status assigns to the ticket with a bug when any new defect is found and logs into a tracking system for the first time. Usually, it is a QA Engineer's responsibility.
Assigned
This status assigns to the ticket with a bug after the QA Engineer reported a bug in the tracking system, and a newly created defect is assigned to the development team to work on the defect. The ticket status changes from New to Assigned. Usually, the ticket status changes to assigned by the Project Manager or QA Lead, or QA Engineer changes it by himself in case he knows which of the developers is responsible for the functionality in which an error was found. There can be two scenarios, first that the defect can directly assign to the developer, who owns the functionality of the defect. Second, it can also be assigned to the Dev Lead and once it is approved, the defect assigns to the developer.
Open/In progress
This status assigns to the ticket with a bug when the developer starts the process of analyzing the defect and works on fixing it if required. The ticket status changes from Assigned to Open or In progress depending on the stages that are set in the tracking system for a particular project. Usually, it is a Developer's responsibility.
Fixed
This status assigns to the ticket with a bug when the developer finishes the task of investigating and fixing a defect by making the required changes in the code and also verifying these changes. The ticket status changes from Open/In progress to Fixed and passes to the testing team. Usually, it is a Developer's responsibility.
Pending retest
This status assigns to the ticket with a bug when the defect is fixed. The developer assigns the defect to the tester to retest the defect at their end. The ticket status changes from Fixed to Pending retest and pass to the testing team until the tester starts working on retesting the defect. Usually, it is a Developer or Project Manager's responsibility.
Retest
This status assigns to the ticket with a bug when the tester does the retesting of the changed code that the developer has given to him to check whether the defect got fixed or not. The ticket status changes from Pending Retest to Retest. Usually, it is a QA Engineer's responsibility.
Verified
This status assigns to the ticket with a bug when the QA Engineer tested the bug again after it got fixed by the developer. If the bug is not present in the software, the QA Engineer approves that the bug is fixed and changes the status to “verified”. The ticket status changes from Retest to Verified. Usually, it is a QA Engineer's responsibility.
Reopen
This status assigns to the ticket with a bug when the QA Engineer tested the bug again after it got fixed by the developer, but the bug still exists even after fixing it by the developer. The ticket status changes from Verified to Reopen, and the bug goes through the life cycle once again. Usually, it is a QA Engineer's responsibility.
Closed
This status assigns to the ticket with a bug when It is fixed, tested, and approved. The ticket status changes from Verified to Closed and the bug goes through the life cycle once again. Closed is a status that marks the final stage of the bug life cycle. The work is done. Usually, it is a QA Engineer, Project Manager, or Customer responsibility.
Duplicate
This status assigns to the ticket with a bug when the identical problem was already reported in the bug tracking system or the two bugs mention the same concept.
Rejected
Reject status can be assigned to an issue for the following reasons: A bug is not reproducible;
A developer can’t understand the problem;
There are no clear requirements;
A QA engineer misunderstood the requirements;
Improper environment configuration during testing, etc.
The ticket status changes from Open to Rejected.
Deferred
This status assigns to the ticket with a bug when the bug is expected to be fixed in the next releases. The reasons for changing the bug to this state have many factors. Some of them are the priority of the bug may be low, lack of time for the release, or the bug may not have a major effect on the software.
Not a bug
This status assigns to the ticket with a bug when the reported behavior is the expected behavior of the application. The ticket status changes from Open to Not a bug. Usually, it is a Developer or Customer responsibility.
Life example:
Let's take a look at the positive and negative scenarios of the bug life cycle.
Example 1: Positive Scenario of the bug life cycle
So in the beginning, the QA Engineer reports an issue with any bug tracking system. After creating our report, the ticket gets the status New. Upon successful reporting, the Development and Test manager reviews the bug. After reviewing, they decide that the issue must be fixed in the current release, therefore Test Managers set the bug status as Open and assign the bug to the developer.
The developer starts working on the ticket and changes the status to Open/In progress. After making all necessary changes in the code to fix the issue, the developer changes the status of the ticket to Fixed. Usually, after the ticket got status fixed, changes in code are reviewed by the development team, and then the ticket gets the status Pending retest.
Then the QA Engineer starts testing the ticket and changes its status of it to Retest. After performing testing, the QA Engineer doesn't reproduce the issue anymore and changes the status of the ticket to Verified. After our ticket is fixed, tested, and approved by the customer, the Project Manager or Customer changes the status of the ticket to Closed.
Example 2: Negative Scenario of the bug life cycle
In the beginning, the QA Engineer reports an issue with any bug tracking system. After the creation of our report, the ticket gets the status New. Upon successful reporting, the Development and Test manager reviews the bug. After reviewing, they decide that the issue must be fixed in the current release. Test Managers set the bug status as Open and assign the bug to the developer.
The developer starts working on the ticket and changes the status to Open/In progress. After making all necessary changes in the code to fix the issue, the developer changes the status of the ticket to Fixed. After the ticket got status fixed, changes in code reviews by the development team, and then the ticket gets the status Pending retest.
Then the QA Engineer starts testing the ticket and changes its status of it to Retest. But after performing testing, the QA Engineer is still able to reproduce the issue. In that case, the QA Engineer changes the status to Reopen and reassigns the ticket to the Developer or to the Project Manager. The bug goes through the life cycle once again.
Example 3: Negative Scenario of the bug life cycle
In the beginning, the QA Engineer reports an issue with any bug tracking system.
After creating our report, the ticket gets the status New. Upon successful reporting, the Development and Test manager reviews the bug. However, after reviewing the ticket, the Developer lead noticed, that the reported behavior is expected and fits the requirement. In that case, the status of the ticket changes to Not a bug.
Conclusion:
So, if you are asked at an interview: What is a Defect/Bug Life Cycle? The best way to answer is:
A defect life cycle - is a path that a defect follows from its inception to resolution. It starts when the defect is found and ends when a defect is closed, after ensuring it’s not reproduced.
The Life cycle of the bug consists of, but is not limited to, the following statuses