Phases of a Software Bug Life Cycle

May 18 10:53 2022 by Helen Johnson Print This Article

Note: the article was updated in May 2022.

The objectives of any software testing are to check the product for defects/bugs and to ensure that the end product will be less prone to them. Any bug found by a tester has to go through different stages to be fixed. Having an accurate and consistent defect management algorithm and following it enable to fix issues quickly and efficiently. This article will help you understand what a Bug/Defect Life Cycle is, which stages it includes and what processes a defect undergoes during each of them. The knowledge about these stages will allow you to implement a unified bug tracking algorithm for the team, making it easier to monitor the testing process, minimizing the risks of mistakes, and enabling the team to release the application sooner.

The phases that the bug moves through after it has been identified are called Bug Life Cycle or Defect Life Cycle. 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.

Defect Life Cycle includes the following states:

New

When a tester posts the defect to a bug tracker for the first time, it is assigned the status ‘New’. A QA engineer then has to provide the development team with a Defect document, so they will be able to fix the issue.

Assigned

After the bug is posted, the project or testing lead has to verify whether it is a genuine error. If so, the defect is assigned to a developer responsible for fixing it, and its status changes to ‘Assigned’.

Open

Once the designated developer starts working on the reported bug, it is marked as ‘Open’.

Fixed

After the developer makes necessary changes in the code and believes that the issue is resolved, they mark it with the status ‘Fixed’.

However, there are several more phases that a defect might go through during the testing workflow after the development team starts working on it:

Rejected

There are several reasons for the bug to be rejected by the developer:
they might not consider it to be an error;
if the defect cannot be fixed or will not fix;
if the error cannot be reproduced on the developer’s side or if the feature works properly for them.

Deferred

In case the developer decides that there are some other issues in the software that need to be fixed prior to the bug posted by the tester, they change its status to ‘Deferred’. This status can also be used if the defect has no relation to the current build of the application or if the development team plans to fix it in the next releases.

Duplicate

If the developer identifies the defect to be the same as the other one reported earlier or the concept of the bug to be identical to those logged before, they mark it as ‘Duplicate’.

Not a bug

When an issue detected by a QA engineer does not affect the functionality of the software, the developer changes its status to ‘Not a bug’.

Ready for retest (Regression Testing)

The developer passes the altered code back to the tester to perform Regression Testing and check if the defect has really been fixed and will not get reproduced again.

Retest (Regression Testing)

Once the QA engineer starts retesting a new build of the software, the bug is assigned with the status ‘Retest’.

Reopen

If the tester still detects the issue during regression testing, the defect is marked as ‘Reopened’ and starts its life cycle once again.

Verified

In case the QA engineer thinks that the error has been fixed accurately, as per all requirements, they mark the bug as ‘Verified’.

Closed

When the issue no longer exists, the tester assigns the status ‘Closed’ to the bug, which marks the last phase of its life cycle. Notice that only testers should be empowered to close errors.

All in all, during the testing process, it is crucial not only to be able to detect bugs but also to track them. It helps maintain a proper workflow and facilitates reporting the testing results back to developers and managers. Moreover, when the whole team working on an issue follows the Defect Life Cycle, it also makes it much easier for a new person joining a project to understand the progress of testing, as well as helps keep the team aligned and well-coordinated — all to release a stable software of high quality. In terms of saving time, following a unified bug tracking routine enables to prioritize defects and identify trends and patterns in the testing process, which, in turn, leads to fewer delays and iterations (when a defect gets reopened several times). Spending less time and effort on a project allows to boost the team’s productivity, release the software faster, and reduce the app development cost — an actual win-win strategy for you and your customers.