Please explain bug life cycle in details?

Please explain bug life cycle in details

Tags: bug, cycle, life

0 members like this

▶ Reply to This

Replies to This Discussion

Permalink Reply by Samrat Jha. on December 16, 2011 at 12:50pm

Core phases are NEW---> OPEN---> FIXED---> CLOSED. but Interviewer expects you to explain it in depth:-

Have a serious look at the Below described Bug Life Cycle.

1) New --->2) Opened ----> 3) Rejected . ( May be Reopened in future )

2) New ---> 2) Opened----> 4) Deferred.(Those defects which will be fixed in next releases or later in the cycle )

3) New----> 2) Opened----->5) Assigned. ( Fixing Starts )

4) New-->2)Opened-->5) Assigned-> [ After fixes] 6)Fixed--> [ if Retest fails ]-->( 7) Reopened--> 5) Assigned.

5) New----> 2) Opened----> 5) Assigned-----> 6) Fixed--->[ Retest passes] ---> 8) Closed.

Note:- If Problem returns then even the Closed bugs can be Reopened and further Assigned ..

Hope It will surely help You..

Regards:

Samrat Jha.

▶ Reply

Permalink Reply by Nagaraju.Velde on January 26, 2012 at 5:15pm

gud n Thanks

▶ Reply

Permalink Reply by Srikanth Chowdary bhimana on December 16, 2011 at 12:52pm

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.

▶ Reply

Permalink Reply by Jakka on January 27, 2012 at 4:50pm

i.e Once the bug is fixed tester will change the status to Closed/Verified

Let me know the difference between the closed and verified.

▶ Reply

Permalink Reply by Samrat Jha. on January 27, 2012 at 4:55pm

Verified means : Retested and during retesting the tester got to know that the Bug has been fixed.

Closed :- Once the bug has been verified , tester will Close that bug...

▶ Reply

Permalink Reply by Sreenivasa S G on February 5, 2012 at 11:28am

Thanks, This explanation gave me proper idea.

▶ Reply

Permalink Reply by santosh on December 16, 2011 at 1:39pm

from interview point of view u can say like this:

as soon as test engineeer found defect in my current project he has to report using bugzilla(or qc or ny tracking tool ur putting in ur cv) by select status severity,found in version,found in build, if it requires attachments, screen shots and necessary information regarding the defect. in my company we report defect to development lead at the time of reporting the status of the defect is {new} once it is {open} developer fixes the defect and test engineer will be notified of the fixed defect which can be retested aganist new build and will change the status to {fixed} test engineer will perform retesting aganist new build and update the status to {fixed verified}.finally test lead will verify it and changes the status to {closed}.

note: if interview asks will test lead close the defect u say yes in my company test will review and closed the defect.

and apart from this der r other stautus also but this is d way we can tel to the interview

status like:duplicate,not a bug,cant reporduce.will not fix,defered bug etc... vary from company to company

hope this will help u!!!

▶ Reply

Permalink Reply by Manisha Hiware on December 16, 2011 at 3:12pm

Hello Santosh , nice explanation.

but can please tell me if interviewr ask me "How you convinced to developer this is a bug"

if developer is not agree this is a bug, plz tell me the answer this is urgent

thanks for advance

▶ Reply

Permalink Reply by santosh on December 16, 2011 at 3:25pm

manisha:

when developer is not accepting the bug

if developers is at our place then we call him and will reproduce the bug in front of him.(before this we will make sure wid developer environment and testers environment(i.e urs)

if developer is on onsite: then we will giv remote acess to developer reproduce the same defect on developers machine if even though he is not convinced then we will report to TL and will conduct a bug review meeting to discuss weather it is a valid or invalid defect.

hope this will help u!!