Understanding the Bug Life Cycle is an essential part of successful software development. As developers, it’s important to be familiar with the stages involved in debugging and patching software, including reporting, analysis, fix testing and deployment. In this article we will discuss each step in detail so you can gain greater knowledge about how to create safe and reliable software products.
What is Defect/ Bug?
- A defect is a deviation from the requirement specification.
- A bug is an informal name given to a defect.
- A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in
unintended ways.
What is Defect/Bug Life Cycle?
- Defect life cycle is a cycle, which a defect goes through during its lifetime. It starts when a defect is found and ends when a defect is closed, after ensuring it’s not going to be reproduced.
- Life Cycle of defect is related to the bug found during testing.
Description of various stages of a defect/bug
1. New
When the bug is posted for the first time, its state is “NEW”. This means that a bug is not yet approved.
2. Open
After a tester has posted the bug, the lead of the tester approves that the bug is genuine, and he changes the state as “Open”.
3. Assigned
Once the lead changes the state as “Open”, he assigns the bug to the corresponding developer or developer’s team. The stage of bug is now “Assigned”
4. In Progress
Once the developer starts working on the bug, he changes the state of a bug as “in progress”.
5. Fixed/ Resolved
After fixing the issue by developers, the status of the bug or defect is changed to “Resolved’ and reassigned to a tester for retesting.
6. Retest/ Verified
The testing team again retests the fixed issue and its status is marked as retest until testing is complete.
7. Reopened
If the bug still exists even after the bug is fixed by the developer, the tester changes the status as “Reopened”. The bug traverses the life cycle once again.
8. Closed
Once the bug is fixed, it is tested by a tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved.
Reject Status
What is “Reject” status?
Tester thinks that it is a defect and sends it to the developer, but the developer is not accepting that it is a defect. In this case, the developer changes the status of the defect to “Rejected”.
Why we get the “Reject” status?
• Because of requirement misunderstanding.
• Referring the old requirements.
• Because of the improper installation of a product.
• Because of extra features.
Duplicate Status
What is “Duplicate” status?
If a tester logging a bug which is already logged by another test engineer, that is called a duplicate bug.
Why we get the “Duplicate” status?
• Because of common features.
• Another test engineer working on the same module logs a similar defect.
• Suppose, a bug logged by another tester, but the developer did not fix that due to some reason. Now new tester finds the same bug while testing and logs it as a separate defect.
• An old project has some bugs, now tester finds a bug and again he gets the duplicate bug.
• To avoid the duplicate bug first, you must search that bug in the defects list.
Cannot be Fixed Status
What is “Cannot be Fixed ” status?
Tester finds a bug and logs it, but the developer says bug cannot be fixed which means the developer is accepting that the bug exists and he is not in a state of fixing it.
Why we get the “Cannot be Fixed” status?
• Cost of fixing the bug might be more than the cost of bug (cost of bug means loss incurred in the business because of having the bug and cost of fixing the bug is money spent in solving the bug)
• If the bug is in the root of product (ex-if there is a minor bug in the root of a product or in core features, chances are there fixing that bug might introduce a lot of another bug).
• If relevant technology does not exist to fix the defect.
Postponed/Deferred Status
What is “Postponed/Deferred” status?
Developer accepts that it is a defect but he says that he wants to fix it later, because for some reason.
Why we get the “Postponed/Deferred” status?
• There might be a minor bug and the developer is not having sufficient time to fix it.
• The customer wants some changes in the project, developer predicts that the changes might be needed in the module in which bug found. So they will wait for the customer, after that according to need, he will fix the bug.
Not Reproducible Status
What is “Not Reproducible ” status?
Tester is able to see the bug, but the developer is not able to see the bug even after following the steps recommended by the tester, this stage is called “not reproducible”.
Why we get the “Not Reproducible ” status?
• Because of improper defect report prepared.
• Because of using the incorrect platform, the tester might be using different OS and browser and developer might be using some other OS and browser or some other version of the browser.
• Because of the inconsistent defect.
What is “Request for Enhancement/REF”?
If there is some problem in software, but it is not part of requirement specification initially
provided, then it is called as an enhancement.
Ex- if we want to delete all emails once and there is no “select all” button then you must select all checkboxes. So, this is not a defect because it is not in the requirement, it is called as an enhancement.
Defect life cycle chart
Prioritizing: Assigning importance and urgency for fixing the bug based on its impact to users or system performance .
Prioritizing is one of the key steps in the Bug Life Cycle. It’s important to assign importance and urgency for fixing the bug based on its impact to users or system performance. When prioritizing bugs, it’s essential to consider the size and type of bug, how long its been around, how quickly they need it fixed, and how much impact it will have on their users or customers. Prioritizing bugs properly ensures that the most critical bugs are addressed first, saving time and providing a better user experience.