Bug life cycle » Bug life cycle

Bug life cycle
bug-life-cycle.png




124 comments ↓

#1 rakesh G A

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.

#2 Shailesh Raj

Nice text, its very useful with simplicity…

Thanks Rakesh G!

#3 Sunil

More informative, explained very clearly it is very help full… thanQ very much for good post.

#4 kanika

awsum man… :)

#5 Mala

Its very simple to understand.
Thank you

#6 Ganesh chandanshive

Thanks Rekha G A …..
Very helpful topic discussed above …..

#7 Chandrakanta

Thanks a lot Rakesh G A
Nice one

#8 Michel

Thanks a lot, concise and clear.

#9 Adarsh Kumar

Thanks Rakesh GA….Really it is very simple and useful..

#10 venkat

excellent

#11 venkat

excellent preparation rakesh. very good performance. I will appreciate your training……

#12 Manas

It great :) Thanks a lot.

#13 Manas

Its great :) Thanks a lot.

#14 Naveen

Thanks a lot

#15 Anita

The way you have explained is very spoon feeding…thnk u

#16 Jegadeesh

Received a good clarity

Thanks

#17 URUSA

Its perfectly given step by step and very easy to understand

#18 Ramana murthy

Useful Info…thank you friends!

#19 Abhiram

Thanks…. useful info

#20 vishal c.

awesome information..!!

Thanks sir… :-)

#21 Aditi

nice article .thanks

#22 Shubha

Easy and effective article on testing for freshers .. Thank u boss :)

#23 Meeta

Can we raised a new bug and mark 3-4 of the old bugs as it’s duplicates? is that valid in the cycle?

#24 Arunadevi

Easily and clearly understandable … Thank u :-)

#25 Namrita Kachroo

Excellent Knowledge :) Tahnks a lot

#26 Milly

Thanks .Its really helpful :-)

#27 Syam Ghana

The concept explanation in simply awesome. Thanks for info ;)

#28 Gopinath

Tnks alot

#29 Karthik

Thanks for the info. Very informative with simple words.

#30 madhavi

please can any body tell the difference between QA and QC, how they are related

#31 Milly

Its really useful for testing

#32 Ballee

Ya!!! Its very useful.. Awesome share….Cheers Man!!!!!!!!!

#33 shalini

it was very useful…………..thanks a lot

#34 Ravi

Article is very simple enough to understand. Thanks.

#35 obanna

Thank’s a lot Rakesh

#36 mahesh

very good

#37 Nil Shriwas

Nice Article, Its very-Very Simple…………

#38 Aabha

bug life cycles

1.New
2.Open
3.Assign
4.Fixed
5.Reopen
6.Closed

#39 Nikhil

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

#40 sri

its so good yar

#41 masood

excellent explanation Rakesh ji….very good notes…simply understanding

#42 sashh

Its really good to undertand , can you update more about testing?

#43 Mayura patel

V. gud Explanation……….pls tell me about STLC procedure also…………

#44 Shaji

What would be the defect status when the retest is pending because of another defect?

#45 shivling

thanks..

#46 Prince

Its a good one… Thanks!

#47 pradeep

its good

#48 sai

good explanation

#49 Bala

very nice …..very simple to understand…

#50 Mousumi

Nice explaination!!

#51 Ratnakar

Its effected answer, nice exact answer

#52 Ganesh

Thanks a lot… :)

#53 chetan

nice text it is very useful to me

#54 raj

simply superb and very understandable ….

#55 sandhya

excellent information on Bug Liffe Cycle

#56 Ramu P

Very nice one…Thanks

#57 Rajani

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.

#58 Gyanaranjan

thanks ,it’s a nice post

#59 vivek

it’s very nice explanation. Thank you.

#60 Abhijit

Even for someone who has no clue about software testing,this explanation is lucid and clear enough for understanding.

#61 palin

thanks bro…nice info….

#62 Sakte

Awesome work ;)

#63 renuka

good explination.Thanks rakesh

#64 chinnu

hi its soo clear answers for every questions frnds..nice

#65 chinnu

may i knw the starting salary for a manual tester wthout any experience..

#66 chinnu

may i knw the starting salary of a manual tester..please gv me a reply

#67 chinu

may i knw the starting salary of a manual tester please …reply me

#68 Anuj jain

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 .

#69 Sowjanya

very nice. ThanQ.
Explain SDLC process also.?

#70 Vishal Gondalia

Nice Material …
Very Useful

#71 Brian

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…

#72 manikandan mugavoor

this is easy to understand………to the material……….thank you……very much the book

#73 Ramya

its very useful

#74 Abhi

nice artical

#75 srinu

awesome….. :-)

#76 Sivaraj

Can anybody tell me how is future for manual tester.

#77 thulasiram

Is Duplicate the is the End status ?
or it needs to be taken ahead with other status to mark it closed.(i mean withdrawn ?)

#78 srinivas

thanks alot, we can understand very easily and the way they have present is excellent…..

#79 amol

i was asked in the interview whose responsibility to fix defered bug in next releases

#80 Siva

nice one..thanks a lot

#81 Maha

i think its Nageshwar Rao notes from MIND Q say some thing new what is happenning in the real time

#82 simna

good one

#83 prachi

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.

#84 vaishali

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

#85 Simna

Good one!!!:)

#86 Archana

simple and valuable details to understand easily : )
Thanks a lot

#87 swapna

Hi friends this article is really good but have to provid with life cycle image for getteing 100% calrity of bug life cycle .

#88 Arya

Its very simple and usefull…. :)

#89 Trivikram

Thanks for an informative post. Gives a clear idea. Keep posting.

#90 samiksha

gud material, it is very helpful….

#91 Navya

Superb:-

#92 Lakshmi

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!!!!!!!

#93 yous

wat if the reason of the bug changed !!! and it is still abug but for different reason

#94 Medhasree

this was a very good information on bug life cycle.Please tell some interview questions on the current company(for exp),audits

#95 Pradeep

good 1…simple and very useful..

#96 pravin

Article is very simple enough to understand. Thanks.

#97 vaibhav

Usually companies follows.

New
Resolved
If not resolved ReOpen
Close

#98 Trinesh

really good…and conversation down the artical also good.!!

#99 MUHAMMAD UMAR ZAMAN

NICE ONE DEAR

#100 Muthu

Thanks man

#101 ashish

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

#102 Sujitha

Awesome content!!! Thanku Rakesh.

#103 Manoj sharma

thks so much. such a nice article.

#104 karthik

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.

#105 priya

thanx alot…..

#106 Shilpa

Very nice explanation rakesh…. thanks a lot

#107 radheshyam

good content ,better understandable

#108 jmd

thanks buddy! great work…

#109 raja

good material, it is very helpful for me…………….

#110 rahul

it’s very nice to understanding

#111 SANGEETHA

thx a lot….if u explain with the bug life cycle dia it ll be more useful for me..thx nice explanation..

#112 mownica

shud have put a graphical representation .wud have been more informative and easy to understand….

#113 Janessa

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

#114 Deepak

I want to same article about the Defect Tracting Tools

#115 khayyum

It’s good but it’ll be very good if it’s described in a diagramatic way.

#116 karishma

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 :)

#117 nivetha

thank u rakesh..it was a nice explanation

#118 lakshmanan

very nice rakesh for giving info about bug life cycle

#119 chiranjeevi

thanks u rakesh …now i am cleared

#120 sankaralingam

Helpful for tester

#121 Nilesh patil

Hi Sir,
You really use such a simple language to undestand the Bug Lige cycle concept so easily,Thanks to you !!!

#122 Shanaka

Thank you very much !!!!

#123 TAPAS

bug life cycle have different states that are
1.entered
2.rejected
3.duplicate
4.deffered
5.assign
6.resolved
7.reassign
8.conclude

#124 priyesh mishra

Hello ,

Can u change any bug life cycle or modify bug life cycle during testing a same web application?

Leave a Comment