Importance of Bug Life Cycle in Software Testing
Make data easy with Helical Insight.
Helical Insight is the world’s best open source business intelligence tool.
Introduction:
Mistakes lead to the introduction of defects (also called bugs). like all human beings I can make mistakes at any point in time, no matter what I might be working on. So it is on projects, where the business analyst can put a defect into a requirements specification, a tester can put a defect into a test case, a programmer can put a defect into the code, a technical writer can put a defect into the user guide, and so forth. Any work product can and often will have defects because any worker can and will make mistakes! Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software.
Bug Life Cycle:
In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced.Below find the various states that a defects goes through in its life-cycle. The number of states that a defect goes through varies from project to project. Below life-cycle, covers all possible states.
Testing
- New: When a defect is logged and posted for the first time. It is assigned a status NEW.
- Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as Assigned.
- Open: At this state the developer has started analyzing and working on the defect fix.
- Fixed: When developer makes necessary code changes and verifies the changes then he can make bug status as ‘Fixed’ and the bug is passed to testing team.
- Retest: At this stage the tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and change the status to “Re-test.”
- Verified/Resolved: The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified/Resolved”.
- Reopen: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. Once again the bug goes through the life cycle.
- Closed: Once the bug is fixed, it is tested by the 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.
- Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate”.
- Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.If the developer feels the defect is not a genuine defect
- Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status “Deferred” is assigned to such bugs
- Not a bug: The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the application.If it does not affect the functionality of the application then the status assigned to a bug is “Not a bug”.
- Known bug:These are problems known to exist at the time of this (Current)release.It is same as Deferred status.
Conclusion::
Make data easy with Helical Insight.
Helical Insight is the world’s best open source business intelligence tool.
While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal.The challenges of following a bug life cycle are far outweighed by the benefits derived. A well planned and closely managed defect database not only tracks current defects against any number of builds and/or products, it also provides a virtual paper trail for the overall progress of a product as it is coded, tested, and released. If sufficient time is provided for building a defect tracker that works for your company, it is more likely you will release a less buggy product, or at least a product where most of the big ones have not gotten away.
Best Open Source Business Intelligence Software Helical Insight is Here
