Just like a real life bug a software bug is also born and later bloom to attain many stages before dying i.e. getting closed. These stages so generic that each defect or bug can fall under its stages.
A bug/defect is always managed by a bug tracking system and
there are lots of bug tracking systems available nowadays, this includes JIRA,
BugZilla, TFS , TeamTrack, etc. the list is very large of such bug tracking
systems. The choice of a bug tracking system totally depends on the business
and the features required.
Though there are very generic stages of a bug life cycle
still each bug tracking system follows its own cycle for a defect. All of those
stages can later be mapped to generic bug life cycle (Refer to Diagram). A typical bug life cycle
is explained here for a basic understanding.
New:
Life of a bug start with very discovery of a bug i.e. with
the point of time when it is identified but in a bug tracking system life is
considered to be started at a point when bug is first logged in the system and
that state is commonly referred as New. That simply means that the bug i very
much new and no work is done on it.
At this point no one can be sure of the person who is going
to fix the defect but the defect remained in the system and can be discussed
during team meetings.
Assigned:
Once the defect is assigned to a developer its state is
changed to assigned, it simply means that a developer is working on the defect
and the resolution can be provided soon. But a defect being in a stage does not
always guarantee that a fix will be provided because at this point developer is
going to study the defect which can lead to any result even to the rejection of
defect.
From Assigned state
defect can achieve three different stages which are explained here respectively:
Researching:
Many of the time developer needs to do some research to know
more of the defect or to explore additional stuff in order to understand the behavior of defect and hence the state of defect can be set to researching
till developer is researching. Once the research is completed defect is sent
back to assigned state and developer can start working on providing the fix or
can take other actions.
Defer:
The defect can be deferred if it is scheduled for a later
release or some other reasons. Thus the state Deferred. The defect can only enter
to state "New" from here similar to reopen from closed state. Please
note that though this state is very much equivalent to closed but it is not
exactly closing the defect because at deferred state we do not have a
resolution for the defect but at closed state we have a resolution of defect.
Test:
At this state the defect is assigned to a test team member
once the resolution of defect is provided by developer. A defect from assigned
state can be sent to a tester with many of the resolutions that includes
providing a fix or rejection of bug. Here, tester has to carry out required
tests to verify the fix provided by developer or he can provide extra
information to developer in case of rejection and send it back to assigned
state.
In case of the fix, if all the testing goes well and tester
does not find any issues then he can close the defect and so is the state
closed. If at any point tester found any issue he can send the defect back to
developer in assigned state with reason as "retest failed" and here
developer again has to work on the issue and can come up with a resolution as
described in Assigned state.
Closed:
If the testing for the defect proves that the defect is
fixed than the defect's state can be changed to closed which means the defect
is now fixed. This state can be achieved from deferred state as well e.g. if a
defect was uncovered at a time and was sent to deferred state after few
releases that issue becomes irrelevant and hence can directly be closed.
Once a defect is closed it doesn’t mean it cannot be
observed again in the software. Though it is very rare but if same defect is
observed again then the defect at state closed can be reopened and sent to New
state.
These are very generic states a Bug/Defect can have and
these can further be divided into other states as per the implementation of a
bug tracking system.
