When writing even the smallest program, a developer can sometimes make mistakes. Such errors are called bugs.
Each bug has a life cycle, a sequence of stages that a bug goes through from the time it is created until it is closed. An error can be reported to the developer by users, testers, or other developers working on the program.
The life cycle of a bug starts at the moment a developer is notified of the bug. However, the start of this cycle does not necessarily mean that the error exists or exists for all users. Maybe the bug can be detected only when specific settings, versions, computers, and other factors are in play. One user may experience it, while another may not. And in general, this may not be a bug but a feature of the program.
Stages of a Bug Life Cycle
You need to know the life cycle of a bug to understand its status, quickly and correctly describe the bug, file it, and close it in the bug tracking system (for example, Jira).
Each stage of work with a defect is called a "status." At any stage, the status shows progress related to an error and who is currently working on it. The status changes when one of the developers finishes work on an error. The error passes "under the authority" of the next developer, who continues working on it.
The names for different life stages of defects vary depending on the bug tracking system, but their essence remains the same. Here are some stages you will encounter.
1. New
The tester found a bug and successfully entered it into the bug tracking system.
2. Open
Once a tester submits a bug, the person who needs to analyze it (usually the project manager) is automatically or manually assigned. Depending on the decision of the project manager, the bug can be:
- Deferred
Fixing this bug has no value at this stage of development, or there are other reasons to delay fixing the defect.
- Rejected
A bug might be considered irrelevant or not seen as a defect, causing it to be rejected.
- Duplicate
If the described error has already been submitted on the bug tracking system, its status changes to "duplicate."
- Assigned
Once a bug is confirmed, a developer is assigned to fix it for the next build.
3. Fixed
The developer responsible for fixing the bug claims to have fixed it. Depending on whether the developer successfully corrected the defect, it can be:
- Verified
The tester checks if the developer fixed the defect. When the bug no longer appears, it receives this status.
- Reopened
If the bug is not fixed in the new build and still needs correction, it is reopened.
4. Closed
After a varying number of cycles, the bug is fixed and no longer requires the attention of the development team. The bug is now declared closed.
Conclusion
These are the main stages of the defect life cycle. Companies might add steps due to their specific testing process, but the life cycle will always start with the bug being created and end with it being closed (or ceasing to exist). Using this guide will help you correctly answer interview questions about the life cycle of a bug.