Want to know what a bug or a defect life cycle is?

Did you find it difficult to understand?

Here we are to simplify it for you.

“Don’t fix bugs later; fix them now.”

Steve Maguire

That’s so true. We should not wait to fix a bug. But to fix and close a bug, you need to understand the basic lifecycle of a bug. To close a bug, it must have been through all the stages of the lifecycle.

But What exactly is a Defect and a Bug?

The defect is a variation caused between the actual results and the expected results. A bug is an abnormal behavior of the software.

A bug starts when the defect is found and ends with it’s closure. Closure of the defect is done after ensuring that the defect is not reproduced.  

What is a Defect Life Cycle (DLC)?

Another name of the DLC is ‘Bug Life Cycle’. The Cycle represents a journey or a set of stages that a defect goes through. It starts right from the identification of a defect and till the closure.

The number of stages of a bug life cycle is not consistent across all organizations. It varies from company to company, and also from project to project, depending on various other factors like policies, the model used in the software development process (e.g.: Agile), Timelines, Structure of the Team etc.,

The software defect life cycle is also governed by the software testing process that is being followed and the defect tracking tool the organization is using.

Defect Life Cycle or A Bug Life Cycle – Diagrammatic Representation

The following diagrammatic representation shows us the various stages of an extensive Bug life cycle.


The following are the various stages of a defect/bug life cycle:


When a tester identifies, logs, and posts a new bug for the very first time; The status will be recorded as ‘NEW.’

Once the bug is logged and posted by the tester, the team-lead of the testers will approve and assign it to the developer team lead or directly to the developer who owns the functionality of the defect. If the bug is assigned to the developer team lead or a dev lead, he will then approves it and moves the defect to the developer.  


When the developer starts working on fixing the assigned defect, the status will be assigned as ‘OPEN.’


When the developer makes all the necessary changes and verifies such change in code, then the status will be updated as ‘FIXED.’

Pending Retest:

The fixed defects will then be available to the tester to retest. As this testing process will be pending from the tester’s end, the status will then become ‘Pending Retest.’


The tester will then retest the code, to find whether the developer fixed the defect. He then changes the status to ‘RETEST.’


Tester retests the code after the defect/bug is fixed by the developer. During the retest, if there is no bug detected in the code, then the status will be assigned as ‘VERIFIED.’


If the bug is still present in the code even after the developer fixed it, the tester will change the status of such defect to ‘REOPEN.’ The bug will once again go through the life cycle.


If the tester finds that the defect is no longer exists, then the tester will change the status to ‘CLOSED.’


If the defect has appeared twice, or if it parallels to the same concept of the previously raised and closed bug, the status will then become ‘DUPLICATE.’


In case the developer opines that the defect is not a real defect, then he changes the status to ‘REJECTED.’


If the defect/bug found is not of a high priority or is not a part of the current release, but it is expected to be fixed in the next build, then the status will be ‘Deferred.’

Not a Bug:

If there is a presence of a bug/defect in the code, but it does not affect the core functionality of the software application, then the status assigned to the defect is – ‘NOT A BUG.’


Some organizations may opt for a Simpler Life Cycle, which may not contain all the stages. Are we clear? Do you have more doubts?

Drop us a comment or a mail to know more.