Defect Life cycle, in other words Bug Life Cycle is the journey of a defect starting from the discovery to closure. It is necessary to understand and properly implement different phases of Bug life cycle in order to comply with STLC standards.
In the Image below you can see different states of Defect. Phases of Defect Life Cycle varies from organization to organization and different Defect Tracking Tools are having their own configuration. Hence, we have tried to cover most utilized and important phases.
Below are the main Contributors of Defect Life Cycle :
Tester : A person who finds / reports the Defect
Project QA Lead : Manages the Defects status and keep eye on some factors like “Defect detection rate”, “Defect Re-open ratio” etc. (Not always required, Tester can handle this responsibility)
Dev Lead : A person who assigns the defect to respective Developer
Developer : A person who works on the defect
Let’s have a look at Defect Life cycle’s graphical presentation :
Now it’s time to discuss about each phase in detail.
While testing any feature of the application, tester finds a flaw or unexpected behavior which is reported as a defect. That’s where our defect life cycle kick starts. The very initial state of any defect is Open and assigned with a unique ID.
After creation, the defect is assigned to the respective developer who is supposed to work on that issue. Here we can have multiple workflows.
– Tester reports the defect and assigns directly to the developer.
– Tester reports the defect and assigns to Dev Team lead. Now it is Dev Lead’s responsibility to assign the defect to respective developer.
– Tester reports the defect and assigns to Dev Module Owner and through him it reaches to a developer for resolution.
All the methods are valid and implemented based on the nature of the project and team size.
Valid Issue ? :
– Bug is now in developer’s bucket and he verifies it is the actual defect or not. If the defect is valid than he starts working on solving it otherwise Defect is assigned back to Tester as “Rejected”.
Now there are multiple reasons under which a defect gets rejected. If the developer feels the bug is not genuine, than he Rejects the defect. If there are multiple Testers working on same module than it is possible that duplicate issues get reported. In such cases Defects are given status as “Duplicate” and assigned back to tester.
There is one more state called “Deferred” which is given if the bug is expected to be resolve in next release(may be due to low priority).
In all these states, a tester needs to confirm the Defect is actually Not genuine or duplicate.
In Progress :
Developer has accepted the defect and he/she starts working on the defect. During this period Bug status remains In Progress.
Finally developer has resolve the defect and he has assigned it back to Tester for confirmation with the status as “Fixed”.
Tester has verified the defect as fixed and marked the state as “Resolved”.
If the defect is not resolved than Tester can also re-open it and assign back to the developer.
Once the defect is resolved and no longer exists, it is “Closed”.
That’s it for the Defect life cycle. You are aware how essential it is to write a proper Defect Report. Want to know how to write a complete Bug Report? I know you do. Click below link: