Thread: Assigning status to the Bug Report

Hai Friends
What is the Defect Life Cycle?

With diagram Plz
Step 1 : 1st time Identify the defect. What is the status of the Bug. Is it Subbmitted Bug or New?
2. To sending the bugs to Developers that time wl change the status (Open or Same as it is submitted?)

Thank U in advance.
Vasantha.

Hi Vasantha,

Just one small addition to the Defect status mentioned by Sridhar...

I suppose once a defect is Opened, It can branch out in 2 different paths.
One is where it is Fixed - Reopened - Closed (After Defect re-Testing).

The other would be where the Defect is Deffered - Developers suggest that it can be fixed in this build and would be deferred / postponed to the next build.

In that case the Branch would be New - Open - Deferred.

Cheers....

Hi vasantha, defect life cycle even depends on the bug tracking tool which you are using in your company. I am familiar with quality center 9.0 . New-> tester will find a new bug(qc will provide the status automatically) open->dev will open the bug and he willl start working to fix the bug fixed-> dev fixed the bug and he changes the status re-test-> a new build is released and dev will change the status close-> tester will put the status as closed,when the bug is not getting reproduced 2. New open cant not reproduce -> if dev is not able to reproduce the defect logged by us,dev will change the status re-open-> after providing the necessary information,a tester will reopen the defect fixed retest closed 3. New open need more information [/b]-> dev will change the status,if he is not able to understand the "steps to reproduce" written by a tester. Re-open fixed retest closed 4. New duplicate -> when the same bug is already raised by some other tester (status is changed by developer) close-> tester will close the defect) note: the status of the defects and even the priorities and the severities can be customised in the bug tracking tool. Hope that it will be useful to you.... Thanks, krishna. --the undertaking of a new action brings new strength-------

pThe status field indicates the general health of a bug. Only certain status transitions are allowed. The resolution field indicates what happened to this bug.
UNCONFIRMED
This bug has recently been added to the database. Nobody has validated that this bug is true. Users who have the "canconfirm" permission set may confirm this bug, changing its state to NEW. Or, it may be directly resolved and marked RESOLVED.
NEW
This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED.
ASSIGNED
This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED.
NEEDINFO
More information from the reporter is needed to proceed further in fixing this bug.
REOPENED
This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED. No resolution yet. All bugs which are in one of these "open" states have the resolution set to blank. All other bugs will be marked with one of the following resolutions.
RESOLVED
A resolution has been taken, and it is awaiting verification by QA. From here bugs are either re-opened and become REOPENED, are marked VERIFIED, or are closed for good and marked CLOSED.
VERIFIED
QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Bugs remain in this state until the product they were reported against actually ships, at which point they become CLOSED.
CLOSED
The bug is considered dead, the resolution is correct. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED