I am sure you have encountered this question many times before!
Interviewer: Can you tell me your bug life cycle process?
Me: Immm, emmmm, oooovvvv….
No, don’t worry so much, actually the process is very simple, you just have to systematize it to tell it in your head :)
In this article, I will try to tell you how the Bug Life Cyle works and what the steps are in the simplest way. In fact, it is one of the most important issues regarding software testing engineering processes is ‘’Bug Life Cycle’’.
Systematic process for dealing with defects: Bug in software requires a process of its own. You should follow this process systematically so that it will be easier to find the main source of the problem and resolve it by communicating it to the responsible person.
Bug life cycle represent the flow of bug: Here, we will talk about the complete life cycle of a bug from the stage it was found, fixed, re-test, and close. We have some different status of bugs like new/open, assigned, fix, re-open, and closed.
The duration between the first time bug is found (stage:”new”) until closed it successfully (stage:closed) is called bug life cycle.
- Find a new bug — → New: This is the first case of a bug in the Bug Lifecycle. When any new defect is founded by test engineer, it becomes ‘New’ and validations and tests are performed on that bug later in the bug Lifecycle.
- Open a bug ticket — → Open: When the bug is assigned to the development, while he is analyze the bug that time he will put the status to OPEN.
- Assign to a developer — → Assign: Once the tester logs the bug, the lead validates the bug and assigns it to the development team. Then the status of the bug is set to ASSIGN.
- Fix → fixed: Here the developer starts the process of analyzing the defect and tries to fix it if necessary. If the developer considers the defect to be inappropriate, it may be transferred to one of the following four statuses:
- Reject: If the developer feels the defect is not a genuine defect then it changes the defect to “rejected.”
Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to “duplicate.”
Not valid bug: If it does not affect the functionality of the application then the status assigned to a bug is “Not a bug”.
- Deferred (postpone): Sometimes the developers will accept the bug, but may be due to the priority, severity or due to time he may push the fix to other releases rather than the current release. Then the bug status will be DEFERRED.
5. Retest: Once the developer fixes the bug, he changes the status to READY TO RETEST. This means developer has fix the issue and is ready for the test team to retest the defect.
6. Close: Once the bug is fixed and the status is VERIFIED. Then lead changes the status to CLOSED.
- Reassign: If any problem persists in the defect, it is reassigned to the developer for testing and the status of the defect is changed to ‘Reassign’.
I hope it has been a useful article series for you as well. I will share my experiences and learnings with you when I can.
Emre
