Quality Testing

Quality is delighting customers

Hi all,

Could any one explain what is Bug life cycle ?

Thanks in advance,


Views: 287

Reply to This

Replies to This Discussion


Bug life cycle is nothing but the cyclic process which happens from opening a bug till it get fixes

The steps which comes under bug life cycle are

1) New (tester founds the bug and post it )
2) Open (developer opens or view the bug)
3) Fixed (where developer changes the code and fix the bug)
4) verified and closed (once the bug is fixed by developer, we have to retest and if it works correctly it should be closed)
5) Reopen: (if the issue still exists it wil be reopened by tester)
6) Rejected (if the bug is not valid or if the steps to reproduce is not clear, developer will reject the bug)

These are the process which occurs during bug life cycle
Nice explanation
thanks man
Active, Addressed, End.

Under what condition we use Active,Addressed,End????

Under all the conditions. What is the fun of having too many statuses ???
Not a Bug (if developer thinks that bug is not a bug)

Awaiting Clarification (if bug is not clear to developer)

Can not replicate ( If developer is not able to reproduce the bug with give steps)
deferred :A defect that is confirmed by the team to be a bug but the effort to correct it at this time exceeds the ROI (Return On Investment). This can often be the case when a re-design is scheduled for that area of the application or if technology barriers exist that make correction of the bug prohibative.

Bug Life cycle is basically
New/Open -- Usually Testers creates a new bug and assigns the bug to Developer or lead developer. It is not mandatory that only Testers can create/Open... any one related to project can create. some times dev leads also opens few missing requirements as bugs and assigns them to developers

Dev lead assigns the bug to developer

In-Progress -- When the developers starts working on this bug, they can mark the bug with this status to let others know that he is working on it... only few orgs uses this.

Fixed -- Once the issue is fixed and deployed in QA environment, developer assigns this bug back to the owner of this bug

Closed -- Once the testers test the fix and if it is working as per requirement then he will close the bug

Re-Open -- if the fix is not working as per requirement, then the tester re-opens the bug and assigns back to dev team ( it happens in 2 instances. A fixed bug can be re-opened or a already closed bug too)

Differed -- Lead Developer deffer the bug, when he feels that this an issue but not in the scope of this implementation. in most of the cases, Developer differs the bug and assigns the lead developer with proper comments then lead developer approves it and re-assigns back to ticket owner and these bugs will be handled as part of other phase

Rejected -- Lead Developer rejects the bug with the reference of Developer comments when it is not a defect

To be Verified -- For the bugs which should be either differed or rejected will be marked with this status and will be assigned to lead developer to Reject or Differ
Also, when a Business Analyst attention required for particular bug to decide whether it is required to be fixed or not lead developer or tester assigns the bug to the respective BA.

there are some other custom terms are also used but the above ones are more than enough to explain as part of bug Life Cycle

RG Jadhav, BE, MBA


TTWT Magazine





© 2022   Created by Quality Testing.   Powered by

Badges  |  Report an Issue  |  Terms of Service