Bug life cycle in software testing
As the name suggests bug life cycle is the lifecycle of the bug which means it comprises of all the stages a bug will go through before getting closed.
In real world, whenever the tester finds any bugs he reports it to the devilment team by logging that bug in a bug reporting tool. Initially the tester assigns the bug to a developer with its status as New.
As soon as the developer starts working on that bug he change its status to open. Now there could be multiple paths this bug could go through depending on the quality of this bug. It could be immediately rejected by the developer as he is unable to reproduce the bug on his machine. Or he could change its status as deferred as the further development of the functionality related to this bug has been postponed until next or any subsequent release. Or he could mention it as a duplicate bug because a similar bug is already present in New/Open/Reopen status in the bug reporting tool. Or the bug is actually relevant and the developer fixes the bug and change its status to fixed. As soon as the developer is ready to reassign the bug to the tester for retesting, he changes its status to retest and assigns it to the tester for retesting it.
Now, the tester again retests the bug and he could change its status to reopen because the bug is not properly fixed by the developer and it is still open. This cycle of bug status getting changed from fixed -> retest -> reopen continues until the bug is properly fixed Or he changes its status to closed as he is unable to reproduce the bug anymore because it has been fixed by the developer.
The above explained is the bug life cycle that is most commonly used in the real world. The ultimate goal of all this work is to make sure that the bug is fixed properly by the developer and it won’t go into the production to bother the end users of the application.