Bug Life Cycle
Bug Life Cycle starts with an unintentional software bug/behavior
and ends when the assigned developer fixes the bug. A bug when found
should be communicated and assigned to a developer that can fix it.
Once fixed, the problem area should be re-tested. Also, confirmation
should be made to verify if the fix did not create problems elsewhere.
In most of the cases, the life cycle gets very complicated and
difficult to track making it imperative to have a bug/defect tracking
system in place.
See Chapter 7 – Defect Tracking
Following are the different phases of a Bug Life Cycle:
Open: A bug is in Open state when a tester identifies a problem area
Accepted: The bug is then assigned to a developer for a fix. The developer then accepts if valid.
Not Accepted/Won’t fix: If
the developer considers the bug as low level or does not accept it as a
bug, thus pushing it into Not Accepted/Won’t fix state.
Such bugs will be assigned to the project manager who will decide if
the bug needs a fix. If it needs, then assigns it back to the
developer, and if it doesn’t, then assigns it back to the tester who
will have to close the bug.
Pending: A bug accepted by the developer may not be fixed immediately. In such cases, it can be put under Pending state.
Fixed: Programmer will fix the bug and resolves it as Fixed.
Close: The fixed bug will be assigned to the tester who will put it in the Close state.
Re-Open: Fixed bugs can be re-opened by the testers in case the fix produces problems elsewhere.
|