Download Link for your Favorite Presentation is at the End of this Page
******************************************************************************************
Know All about States of your Bug
Various States of a Bug during its Life Cycle:
Bug refers to a fault or defect in software program due to which the software behaves abnormally. Truly speaking Bugs are inherent to software, rather it is difficult to find a software without any Bug. Removal of bugs from the software depends upon the efficiency of the testing activity performed on the software. Bug attracts special concerns which reflect on the quality of the Application under Test
Life Cycle of Bug:
In software development process, every bug has its own life cycle across which it passes through before getting closed. As a matter of standardization, specific life cycle is defined for the Bugs. During its life cycle, the bug attains various states, which are illustrated below
Various States of a Bug during its Life Cycle are:
1. New Bug: When a bug is posted for the first time, its state is called “NEW”. This implies that the bug is not approved yet.
2. Open Bug: Once the software tester posts a bug, the team leader approves it after satisfying himself about its genuinity, and changes its state to “OPEN”.
3. Assigned Bug: Once the lead changes the state to “OPEN”, the bug is assigned to the concerned developer team. The state of the bug is changed now to “ASSIGNED”.
4. Test Bug: Once the developer fixes the bug, he transfers the bug to the testing team for next round of testing. After fixing the bug & prior to releasing it back to the testing team, the state of the bug is changed to “TEST”. In other words, the state “Test Bug” implies that the bug has been fixed and is released to the testing team.
5. Deferred Bug: When the bug is expected to be fixed in next releases, its state is changed to deferred state. Many factors are responsible for changing the bug to this state. Few of such factors 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.
6. Rejected Bug: If the developer feels that the bug is not a genuine one, he rejects it. This leads change of state of the bug to “REJECTED”.
7. Duplicate Bug: If a particular bug gets repeated more than once or two bugs point towards the same concept, then the status of one of the bug is changed to “DUPLICATE”.
8. Verified Bug: Once the developer fixes the bug and its status is changed to “TEST”, the software tester confirms the absence of the bug. If the bug is not detected in the software, the tester approves that the bug is duly fixed and changes its status to “VERIFIED”.
9. Reopened Bug: If the bug is detected again even after the bug is claimed to be fixed by the developer, the tester changes its status to “REOPENED”. The cycle repeats again & again till the bug gets ultimately fixed & get closed.
10. Closed Bug: Once the bug is fixed & the tester confirms its absence, he changes its status to “CLOSED”. This is the final state which implies that the bug is fixed, tested and approved.
As is well known that prevention is better than cure, similarly prevention of defect in software is much more effective and efficient in reducing the number of defects. Some organizations focus on discovery of defect and subsequent removal. Since discovering and removing defects is an expensive and inefficient process, hence It is better & economical for an organization to focus their major attention on activities which prevent defects.
Typical Lifecycles of Some of the Popular Bugs are:
- Valid Bug: New -> Assigned -> Fixed but not patched -> Ready for Re-testing -> Closed & Fix has been Verified
- Invalid Bug: New -> Not a Bug -> Closed since it is Not a Bug
- Duplicate Bug: New -> Duplicate Bug -> Closed since it is a Duplicate Bug
- Reopened Bug: New -> Assigned -> Fixed but not patched -> Ready for Re-testing -> Reopened -> Fixed but not patched -> Ready for Re-testing -> Closed & has been Fix Verified
Analysis of Bugs:
Bugs detected & logged during the testing phase provide valuable opportunity to improve the product as well as the testing processes. The aim of every testing team remains to achieve zero Customer Bugs. Majority of the Customer Bugs starts pouring in first 6 Months to 1 year of the product usage.
Immediately after the completion of the product testing, the testing teams should carry out detailed analysis of the entire set of Invalid Bugs / Duplicate Bugs / Could_Not_Be_Reproduced Bugs and come up with adequate measures to reduce their count in future testing efforts.
However once Customer Bugs start pouring in, the testing Team immediately starts analyzing each one of them & try to find out as to how & why these bugs have missed during their testing effort and take appropriate measures immediately.
Many More Articles on Software Bugs
DownLoad Link for Presentation:
Parameterization – Advanced VUser Scripts in HP LoadRunner (496 Kb)
