Lifecycle of the program defects

In order to navigate among the status of the defects, as well as to quickly and correctly create, comment and close them in the bug tracking system, you need to know which way they go.

Defect LifeCycle – this is a sequence of stages that a defect goes through on its way from the moment of its creation to its final closure. For the ease of perception, it is depicted as a scheme with possible statuses and actions that lead to a change in these statuses.

Any stage of work with a defect is indicated in the «Status» attribute. The status of the defect shows who is currently working with the defect and what should be done with it. After one of the project participants has finished working with the bug, he changes the defect status and «redirects» the defect to the one who should continue working.

Often, the lifecycle of a bug is associated with the selected bug tracking system, in which statuses and transitions can be configured by default. But also some of the bug tracking systems allow you to adjust the bug lifecycle for a specific project if it’s necessary. The system can provide administrators the ability to configure which users can view and edit bug reports based on their states, transfer them to another state, or delete them.

New: The report of the defect is entered into the bug tracking system for the first time. 

Assigned: The  report of the bug is assigned to the developer.

Open: The developer takes the defect report to work for the analysis and fix.

Fixed: The developer made the necessary changes to the code and tested these changes himself. A bug report with this status is returned back to the tester.

Standby retest: After fixing the defect, the developer provided specific code for retesting for the tester. Testing is pending with a tester.

Re-testing: On this stage, the tester retests the modified code that was provided by the developer to see if the defect is fixed or not.

Verified: If the defect is not reproducible, the tester confirms that the defect is fixed.

Reopened: If the defect is reproduced, even after the developer fixes it, the tester reopens it and assigns it to the developer again. This defect goes through the defect lifecycle again.

Closed: If the tester is sure that the defect is no longer reproduced, then he closes it. This status means that the defect has been fixed, tested and approved.

Duplicate: If a defect is repeated twice or there are two bugs that are the result of one reason, then one of them is assigned with this status.

Rejected: If the developer believes that the defect is not justified or compelling, and the defect will not be considered for correction or implementation, he rejects it.

Deferred: It is expected that the defect that has been assigned with this status will be fixed in future versions. There can be several reasons for assigning this status: the priority of the defect is low, lack of time, this defect will not entail major failures in the software product.  

Not a bug: This status is assigned if no changes are made to the application functionality. For example, if a customer asks to change the color or size of buttons or text, this is not a defect, but simply a change in the design of the application.

Let's take a closer look at the lifecycle of the defect.

1. The tester finds a defect. 
2. The tester submits a bug report to the bug tracking system (the «New» status) and assigns to the developer (the «Assigned» status).
3. The developer checks the defect, whether it is reproducible or not and assigns it one of the following statuses: 

• «Duplicate» - similar defect is already reported in the bug tracking system;
• «Rejected» - the defect isn’t important;
• «Deferred» - the defect fix can be carried over to the following versions of the software product;
• «Not a bug» -  no changes will be made to the functionalities of the software product;
• «Open»  - the developer started to work on this defect;
• «Fixed» - the developer made changes to the code and tested them.

4.  The tester re-tests the defect (the «Re-testing» status).
5.  If the defect is not reproduced, the tester closes it (the «Verified» status, the «Closed» status).
6.  If the defect is reproduced, the tester returns it to the developer for fixing (the «Reopened» status, the «Assigned» status) and this defect goes through this lifecycle again.

Based on the information about the status of defects in the bug tracking system, you can create the reports, which allow you to evaluate both the work of the developer and the tester. As well as a number of metrics to assess the convergence points of defects and the overall quality of products.