Life Cycle of a Defect

This tutorial lists the various defect life cycle stages that the defect or bug passes through.

A defect is an error or mistake made in an application that makes a system behave differently than desired requirements. Finding a defect or bug in the application code by the developers is the responsibility of a testing team.

The testing team makes sure that all the bugs are found before the application goes LIVE or is available to end-users.

What is a defect or bug life cycle?

A defect life cycle is the movement of a bug or defect in different stages of its lifetime, right from the beginning when it is first identified until the time is marked as verified and closed.

Depending on the defect management tool used (like Bugzilla, Jira, etc) and the processes followed by the organization, we can have different states as well as different nomenclature for the states in the defect life cycle.

The defect life cycle involves the following resources.

• Tester – To find the bug and re-test the solved bug.
  
• Project Lead/ Project Manager/ Test Lead – To verify the bug and assign it to the respective developer.
  
• Developer – To resolve the bug or defect filed by the tester.
  
  
  

Defect Life Cycle

Following are the different stages of the defect life cycle.

New

When a tester finds a new bug/defect, s/he posts it in the bug tracking tool with a status ‘NEW’. With the defect explanation, steps to reproduce the bug and the severity of the bug will also be provided.

Assigned

Once the new bug has been filed, the respective lead or manager (Project Lead/ Project Manager/Test Lead) will approve it and assign the bug to the corresponding developer. After the bug has been assigned to someone, its status changes to ‘ASSIGNED’. While assigning the bug, the priority of the bug is also assigned.

Open

Sometimes as soon as the bug is assigned to someone it has common status i.e. ‘OPEN/ASSIGNED’. Sometimes both are different stages, such as a bug is open but unassigned or a bug is assigned but unopened. Once the developer is assigned the bug and when s/he starts working on it, its status changes to ‘OPEN’.

Rejected/Not a bug/Dropped 

If the assignee (Project Lead/ Project Manager/ Test Lead) or developer finds the bug to be invalid, it is given a ‘REJECTED’ status.

Deferred

Sometimes a NEW or ASSIGNED bug is given ‘DEFERRED’ status based on the urgency and criticality of the bug. A deferred bug’s fix is deferred for some time (for the next releases).

Fixed/In Test/Completed

When a bug is resolved or fixed by the developer, its status changes to ‘FIXED’ and it is assigned back to the testing team. Once it has been tested, if it is solved, its status will be changed to ‘VERIFIED’ and if it is not solved and the bug still persists, its status will be changed to ‘REOPENED’ by the testing team.

Reopened

If the tester is not satisfied with the solved issue, the bug is assigned the ‘REOPENED’ state. Again, the same cycle of fixing the bug and assigning back to the tester goes on until the bug is ‘CLOSED’.

Verified

After the testing, if the tester feels the bug is resolved, it is marked as ‘VERIFIED’.

Closed

After the bug is verified, it is moved to the ‘CLOSED’ state.

With this, we have come to the end of this part of the tutorial. If you have any questions, please ask in the comment section. Also, check out the complete software testing tutorial below.

Software Testing Tutorial