This entry was posted
on Wednesday, September 5th, 2007 at 8:52 am and is filed under .
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
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).
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. 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
Description of Various Stages:
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.
Guidelines on deciding the Severity of Bug:
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:
1. Critical / Show Stopper — An item that prevents further testing of the product or function under test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of this include a missing menu option or security permission required to access a function under test.
.
2. Major / High — A defect that does not function as expected/designed or cause other functionality to fail to meet requirements can be classified as Major Bug. The workaround can be provided for such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc.
.
3. Average / Medium — The defects which do not conform to standards and conventions can be classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples include matching visual and text links which lead to different end points.
.
4. Minor / Low — Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs.
Bug Life Cycle:
1. New
2. Open
3. Assign
4. Fixed
5. Retest
6. Pass or Fail
7. If Pass then Close
8. If Fail then Assign back to developer
9. Again step “4″ onwards status goes on
Ur work is excellent.
Please suggest me how to answer the question when asked what u have done(or how many test cases you prapare or type of testing u perform) on mentioned project lets say in domain Elearning. i am having the idea of the project bt not know how to start and how the flow go on.
Hi,
i have 2 questions
1.what is the difference between verified and closed.
2. after the developer changes to duplicate state will the tester change it to verified or closed
BUG SUMMARY:
? Single line explanation about the bug.
BUG DESCRIPTION:
? The details about bug.
ASSIGNED TO:
? To whom the bug is assigned.
SEVERITY:
? Impact of the bug based on the application.
PRIORITY:
? How important the bug has to be fixed.
STATUS:
1. New
2. Deffered
3. Rejected
4. Duplicate
5. Answer only
6. Open
7. Fixed
8. Resolved
9. Verify and Close
10. Failed.
NEW:
? When the test engineers identify the bug he set the status as NEW.
DEFFERED:
? In some cases the bug is not important for the current release then the status will be DEFFERED.
REJECTED:
? When the bug is invalid then the developer will change the status of the bug to REJECTED.
DUPLICATE:
? When the test engineer identifies the bug if the same bug has been fixed already by another test engineer then the status will be DUPLICATE.
ANSWER ONLY:
? If the bug is due to environmental issues and not code error then he changes the status to ANSWER ONLY.
OPEN:
? Development lead will see the bug. If it is valid then he change the status to OPEN.
FIXED:
? After fixing the bug by developer he change the status to FIXED.
RESOLVED:
? After fixing the bug by developer the new build has been created then the developer will change status RESOLVED.
VERIFY AND CLOSE:
? After the bug resolved then the test engineer will re-execute the test cases when there is no mismatch in the test cases then test engineer will change the status to VERIFY and then CLOSE.
FAILED:
? If the mismatch occurs in the test cases means then the tester will change the status to FAILED.
CC LIST:
? Complete list of e-mail id’s we want to sent.
ATTACHMENTS:
? If any bug is identified then the details of the bug has been attached.
COMMENTS:
? If any bug is modified then the tester will add the commands about the bug.
Great beat ! I wish to apprentice at the same time as you amend your web site, how could i subscribe for a weblog site?
The account aided me a acceptable deal. I have been tiny bit acquainted
of this your broadcast provided bright transparent concept
thank u soo much , from this bug life cycle i learned a lot , thanks for helping me out from this, the matter was very neat nd clean finally awesome job man
118 comments ↓
Introduction:
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).
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. 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
Description of Various Stages:
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.
Guidelines on deciding the Severity of Bug:
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:
1. Critical / Show Stopper — An item that prevents further testing of the product or function under test can be classified as Critical Bug. No workaround is possible for such bugs. Examples of this include a missing menu option or security permission required to access a function under test.
.
2. Major / High — A defect that does not function as expected/designed or cause other functionality to fail to meet requirements can be classified as Major Bug. The workaround can be provided for such bugs. Examples of this include inaccurate calculations; the wrong field being updated, etc.
.
3. Average / Medium — The defects which do not conform to standards and conventions can be classified as Medium Bugs. Easy workarounds exists to achieve functionality objectives. Examples include matching visual and text links which lead to different end points.
.
4. Minor / Low — Cosmetic defects which does not affect the functionality of the system can be classified as Minor Bugs.
Nice text, its very useful with simplicity…
Thanks Rakesh G!
More informative, explained very clearly it is very help full… thanQ very much for good post.
awsum man…
Its very simple to understand.
Thank you
Thanks Rekha G A …..
Very helpful topic discussed above …..
Thanks a lot Rakesh G A
Nice one
Thanks a lot, concise and clear.
Thanks Rakesh GA….Really it is very simple and useful..
excellent
excellent preparation rakesh. very good performance. I will appreciate your training……
It great
Thanks a lot.
Its great
Thanks a lot.
Thanks a lot
The way you have explained is very spoon feeding…thnk u
Received a good clarity
Thanks
Its perfectly given step by step and very easy to understand
Useful Info…thank you friends!
Thanks…. useful info
awesome information..!!
Thanks sir…
nice article .thanks
Easy and effective article on testing for freshers .. Thank u boss
Can we raised a new bug and mark 3-4 of the old bugs as it’s duplicates? is that valid in the cycle?
Easily and clearly understandable … Thank u
Excellent Knowledge
Tahnks a lot
Thanks .Its really helpful
The concept explanation in simply awesome. Thanks for info
Tnks alot
Thanks for the info. Very informative with simple words.
please can any body tell the difference between QA and QC, how they are related
Its really useful for testing
Ya!!! Its very useful.. Awesome share….Cheers Man!!!!!!!!!
it was very useful…………..thanks a lot
Article is very simple enough to understand. Thanks.
Thank’s a lot Rakesh
very good
Nice Article, Its very-Very Simple…………
bug life cycles
1.New
2.Open
3.Assign
4.Fixed
5.Reopen
6.Closed
Bug Life Cycle:
1. New
2. Open
3. Assign
4. Fixed
5. Retest
6. Pass or Fail
7. If Pass then Close
8. If Fail then Assign back to developer
9. Again step “4″ onwards status goes on
its so good yar
excellent explanation Rakesh ji….very good notes…simply understanding
Its really good to undertand , can you update more about testing?
V. gud Explanation……….pls tell me about STLC procedure also…………
What would be the defect status when the retest is pending because of another defect?
thanks..
Its a good one… Thanks!
its good
good explanation
very nice …..very simple to understand…
Nice explaination!!
Its effected answer, nice exact answer
Thanks a lot…
nice text it is very useful to me
simply superb and very understandable ….
excellent information on Bug Liffe Cycle
Very nice one…Thanks
Very nice Website with most of the information. I am in job search actually I don’t have any testing experience.
Can you Provide some general questions like.
Ex:- Any problems that you faced while testing?
Any suggestions on the above question for interview purpose. Really I don’t know what kind of problems we can face while testing.
thanks ,it’s a nice post
it’s very nice explanation. Thank you.
Even for someone who has no clue about software testing,this explanation is lucid and clear enough for understanding.
thanks bro…nice info….
Awesome work
good explination.Thanks rakesh
hi its soo clear answers for every questions frnds..nice
may i knw the starting salary for a manual tester wthout any experience..
may i knw the starting salary of a manual tester..please gv me a reply
may i knw the starting salary of a manual tester please …reply me
Thanks a lot for sharing great knowledge
All the process you descried are very clear and useful for me but if u put an digram also then its the best for all to learn .
very nice. ThanQ.
Explain SDLC process also.?
Nice Material …
Very Useful
How can you mark something “RESOLVED” before QA/Test verifies the code fix is correct??
This diagram above needs to be revamped — sorry but it’s only 70% accurate at best…
this is easy to understand………to the material……….thank you……very much the book
its very useful
nice artical
awesome…..
Can anybody tell me how is future for manual tester.
Is Duplicate the is the End status ?
or it needs to be taken ahead with other status to mark it closed.(i mean withdrawn ?)
thanks alot, we can understand very easily and the way they have present is excellent…..
i was asked in the interview whose responsibility to fix defered bug in next releases
nice one..thanks a lot
i think its Nageshwar Rao notes from MIND Q say some thing new what is happenning in the real time
good one
Hi vijay
Ur work is excellent.
Please suggest me how to answer the question when asked what u have done(or how many test cases you prapare or type of testing u perform) on mentioned project lets say in domain Elearning. i am having the idea of the project bt not know how to start and how the flow go on.
Nice Article.. Before reading this article, I actually dont know anything about Testing but this article helps me a lot to clear my concepts…
Thanks
Good one!!!:)
simple and valuable details to understand easily : )
Thanks a lot
Hi friends this article is really good but have to provid with life cycle image for getteing 100% calrity of bug life cycle .
Its very simple and usefull….
Thanks for an informative post. Gives a clear idea. Keep posting.
gud material, it is very helpful….
Superb:-
Very Nice Explanation about bug life cycle in simple english, it’s very easy to understand!!!!!! Very helpful for freshers
Good Work Rakesh G A!!!!!!!
wat if the reason of the bug changed !!! and it is still abug but for different reason
this was a very good information on bug life cycle.Please tell some interview questions on the current company(for exp),audits
good 1…simple and very useful..
Article is very simple enough to understand. Thanks.
Usually companies follows.
New
Resolved
If not resolved ReOpen
Close
really good…and conversation down the artical also good.!!
NICE ONE DEAR
Thanks man
Hi,
i have 2 questions
1.what is the difference between verified and closed.
2. after the developer changes to duplicate state will the tester change it to verified or closed
Awesome content!!! Thanku Rakesh.
thks so much. such a nice article.
FIELDS IN BUG TRACKING TOOL:
1. Bug ID.
2. Bug summary.
3. Bug description.
4. Assigned to
5. Severity.
6. Priority.
7. Status.
8. CC List.
9. Attachments.
10. Comments.
BUG ID:
? A unique id is given for every bug.
BUG SUMMARY:
? Single line explanation about the bug.
BUG DESCRIPTION:
? The details about bug.
ASSIGNED TO:
? To whom the bug is assigned.
SEVERITY:
? Impact of the bug based on the application.
PRIORITY:
? How important the bug has to be fixed.
STATUS:
1. New
2. Deffered
3. Rejected
4. Duplicate
5. Answer only
6. Open
7. Fixed
8. Resolved
9. Verify and Close
10. Failed.
NEW:
? When the test engineers identify the bug he set the status as NEW.
DEFFERED:
? In some cases the bug is not important for the current release then the status will be DEFFERED.
REJECTED:
? When the bug is invalid then the developer will change the status of the bug to REJECTED.
DUPLICATE:
? When the test engineer identifies the bug if the same bug has been fixed already by another test engineer then the status will be DUPLICATE.
ANSWER ONLY:
? If the bug is due to environmental issues and not code error then he changes the status to ANSWER ONLY.
OPEN:
? Development lead will see the bug. If it is valid then he change the status to OPEN.
FIXED:
? After fixing the bug by developer he change the status to FIXED.
RESOLVED:
? After fixing the bug by developer the new build has been created then the developer will change status RESOLVED.
VERIFY AND CLOSE:
? After the bug resolved then the test engineer will re-execute the test cases when there is no mismatch in the test cases then test engineer will change the status to VERIFY and then CLOSE.
FAILED:
? If the mismatch occurs in the test cases means then the tester will change the status to FAILED.
CC LIST:
? Complete list of e-mail id’s we want to sent.
ATTACHMENTS:
? If any bug is identified then the details of the bug has been attached.
COMMENTS:
? If any bug is modified then the tester will add the commands about the bug.
thanx alot…..
Very nice explanation rakesh…. thanks a lot
good content ,better understandable
thanks buddy! great work…
good material, it is very helpful for me…………….
it’s very nice to understanding
thx a lot….if u explain with the bug life cycle dia it ll be more useful for me..thx nice explanation..
shud have put a graphical representation .wud have been more informative and easy to understand….
Great beat ! I wish to apprentice at the same time as you amend your web site, how could i subscribe for a weblog site?
The account aided me a acceptable deal. I have been tiny bit acquainted
of this your broadcast provided bright transparent concept
Check out my web-site; Janessa
I want to same article about the Defect Tracting Tools
It’s good but it’ll be very good if it’s described in a diagramatic way.
thank u soo much , from this bug life cycle i learned a lot , thanks for helping me out from this, the matter was very neat nd clean finally awesome job man
thank u rakesh..it was a nice explanation
very nice rakesh for giving info about bug life cycle
Leave a Comment