Tutorials TestingIn this tutorial you will learn about Bug Life Cycle & Guidelines, Introduction, Bug Life Cycle, The different states of a bug, Description of Various Stages, Guidelines on deciding the Severity of Bug, A sample guideline for assignment of Priority Levels during the product test phase and Guidelines on writing Bug Description.
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. A bug is a specific concern about the quality of the Application under Test (AUT).
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. The life cycle of the bug can be shown diagrammatically as follows:
The different states of a bug can be summarized as follows:
1. New
2. Open
3. Assign
4. Test
5. Verified
6. Deferred
7. Reopened
8. Duplicate
9. Rejected and
10. Closed
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
5. 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.
6. 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”.
7. 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”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
10. 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.
While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal. Discovering and removing defects is an expensive and inefficient process. It is much more efficient for an organization to conduct activities that prevent defects.
Indicate the impact each defect has on testing efforts or users and administrators of the application under test. This information is used by developers and management as the basis for assigning priority of work on defects.
A sample guideline for assignment of Priority Levels during the product test phase includes:
Bug can be expressed as “Result followed by the action”. That means, the unexpected behavior occurring when a particular action takes place can be given as bug description.
| Bug Lifecycle was defined very well. |
| the life cycle of the bug is defined well with various stages. i like this bug life cycle. we can follow this bug life cycle for the interviews. |
| The explanation was really helpful. |
|
hi. the topic "bug life cycle" is really so good. it has no confusions and everything is written in a very simple and proper manner. |
| A very good explanation .Given in simple english such that every one can understand. |
|
hi description was very good, great work and great help to me |
| It was very neat description with simplicity and easy to understand. |
| The way you have given the description is very good and marvelous, its an interesting matter and this matter helps me alot..thanks for giving me nice information... |
| very good |
|
Hai The description of bug life cycle is very good and understand, and also satisfied very much. |
|
Hai , here i learned complete bug life cycle its very good and neatly explained . Thank you |
|
when the bug is new, QA lead cannot assign the status OPEN or assign to the developer. It is the development manager or lead who assigns the bug. |
|
hi!! well the description was simple and covered the entire aspect of bug life cycle. thankyou and keep up the good work. |
|
Good description to give an overview of bug life cycle. very Nice |
| Really very helpfull... |
| this is really helpful |
| Great Very Helpul. |
| the content you use in whole life cycle is very easy to understand it really sounds well. |
| It is crystal clear....even a lay man can understand now...what is bug life cycle....hats up...to the website...very informative |
|
bug life cycle is very clear and easy understandable thanks for that |
|
Hi: This is sheikh Asgher Ali from Bangalore, could you please elaborate more on Deferred bug. Its not very clear to me, e.g from you definition if the bug is expected to be fixed in next release, and it is not fixed thats the reason it is marked as Deferred due to low impact in software. Looking forward from you, Regards, Asgher. |
|
Hi, Finally I got what Iwas searching for "Bug Life Cycle"........It's too good to to have the knowldge in very short period of time and you have mentained the simplicity with the appropriate explanation. It is very useful for every one right from fresher to Experienced tester....Thanks!!!!!!! :) Sachit..... 91-9960364300 |
|
The description was very easy to grasp and yet powerful.... thanks.. |
| Really a cyclic real time approach,easy to read and more effective |
| Yes, it is exactly as any bug tools follow |
| The explained bug life cycle will be very useful for novice testers. |
| Nice,it's very useful of improve my knowledge.Thank's lot.... |
| description is very good |
| bug life cycle defined very well and easy to understand |
| thank u ...explianed well.... |
| According to the Description of Various Stages the reopen should have an input (arrow) from the 'Verify' stage instead of the 'Test' stage. That would make the flow diagram much more meaningful |
| very understandable |
| Your explanation of bug tracking methods are very simple and understandable. Thanks |
|
Here the bug life cycle is explained detailed with explanation of different stages and statuses. it's very well understandable explanation. |
| sipmly superb |
| Its pleasing explanation. |
| hello it was very informative and quite helpful we expect such answers as it would really be a boost for the readers also a piece of information interesting for that reason they ultimately seek help in this site. really wonderful |
|
excellent information on Defect |
| Bug life cycle has been explained as we expected.Knowledge searcher can come to end if he searched about bug life cycle. Keep going with quality for quality. |
| where does status fixed comes |
| good explanation,however few eg should have also been added which would have realised the concenpt |
| It's really good information. |
| good explanation for the deciding the Severity of Bug and also brief and nice guidelines on bug description. |
| Good explanation, easy to understand. Thanks |
| This is pretty much clear cut description given for the Bug Life cycle such kind of things are very much useful for people who come into this testing platform |
| very good |
| BLC is explained in easy manner. It helped me a lot to understandard the BLC clearly. THANKS A LOT. |
| It helped me a lot to understand the BLC clearly. THANKS. |
| this explantion is very good.this is very help for me. |
| clear notes |
|
This explanation about "BUG LIFE CYCLE" is very clear and easy to understand. It is really helpful. |
|
this topic short and sweet .It gives more information in simple words . keepit up! |
|
Its very clear..good |
| simply superb ,very very well................................................................................................................... |
|
Hi It was very neat description with simplicity and easy to understand. |
|
Hey.. Great ...its really clear. could well understood..of a bug life cycle... |
|
The Bug Life Cycle has been explained well, however i think in Description of Various Stages, author has mentioned contradictory statement in 8th & 10th Stages of a Bug, i.e Verified & Closed. |
| The discription given by u is very nice with very easy language. Every can get it in first reading. I am very thankful to u bcoz it helps me. Great ...its really clear. could well understood..of a bug life cycle... |
| Superb....simple yet profound |
| Vow... really nice explanation with Flow Chart |
| Hip Hip hurray! Simply suberb |
| Very nicely explained....thats what i was looking for.... |
| Bug life cycle very good |
| In this document bug lifecycle is explained very nicely..... good. |
| Really very good explanation.... |
| good explanation, simply superb.... |
| Its very simple to understand.....a waiting for future best articles of yours...:) |
|
1) A tester finds a bug and reports it to Test Lead. 2) The Test lead verifies if the bug is valid or not. 3) The bug is verified and reported to development team with status as ‘New’. 4) The development leader and team verify if it is a valid bug. The bug is valid and the development leader assigns a developer to it marking the status as ‘Assigned’. 5) The developer solves the problem and marks the bug as ‘Fixed’ and passes it back to the Development leader. 6) The development leader changes the status of the bug to ‘Pending Retest’ and passes on to the testing team for retest. 7) The test leader changes the status of the bug to ‘Retest’ and passes it to a tester for retest. 8) The tester retests the bug and the same problem persists, so the tester after confirmation from test leader reopens the bug and marks it with ‘Reopen’ status. And the bug is passed back to the development team for fixing |
| It's very simple and easy to understand. Make my day is easier. |
| it's cool |
|
This article gives exect meaning of bug life cycle. this article is very useful for the beginners. say very good to the author of this article |
| Difference between Severity and priority |
| good n catchy.kep it up |
|
now i understand clear meaning abour BUG LIFE CYCLE this answer is very clear and very easy.For freshers this answer will very helpful. Thanks for this web site sridharraghava@gmail.com |
| very good description........thanx a ton |
| Good Explanation in simple language.... |
| very good description.. and it very usefull...thanx buddy |
| Bug Lifecycle explained excellently |
| Really thank you |
| covered all the aspects in simple words |
| The concept of bug life cycle is explained beautifully |
| Excellent.Quite explanatory |
| gr8 description. precise n easy to understand. |
|
very nice expressed , valuable, any one can understand easily... thanx a lot... |
|
Thanks a lot for nice and simple description but I think you missed to write about 'Priority' part of the Bug. |
|
Sheik, Here is the explanation for Deferred Bug. Suppose if you are testing some application and you encounterd some abnormal behaviour which is not as per the expectations.So you raise the defect and assigned it to the concerned developer. But if he confims the bug has nothing to do with his current code changes, i.e it was already in production and found only during the current release so he can reject it by choosing 'Deferred', so that the same can be fixed in the next release or later som time. Hope this clarifies your doubt. Thanks Sujatha |
| There needs to be an explanation regarding the difference between "STATE" and "STATUS". Most automated defect tracking software have these elements. The list provided in this write up mixes the two together. The State can be OPEN, WORKING, RETURNED, or CLOSED in the most basic sense. Statuses are dictated by where the defect is in the life cycle and who is working on the defect (assigned to the defect). Within the different STATES the status can change from New to assigned, verified, tested etc... |
| There is one thing missing. That is if the developer doesn't nderstand the explanation of the defect or may need more details like the steps executed, exact data that was entered etc, the developer should be able to return the defect to the tester by changing the status of the defect as "INFO REQUIRED". And then the tester will enter more details, answer developer's questions and changes the status to "INFO UPDATED". These steps should be in between ASSIGN and TEST. |
| I do agree with this life cycle. If the developers doesnt understand the explanation given for the defect he could change the status to "CLARIFICATION REQUIRED". If the same has been clarified this has to be moved to "CLARIFICATION PROVIDED". May be these kind of status will differ from organisation to organisation. |
