Bug Life Cycle in Software Testing

Any flaw, error, fault, gap in requirements or deviation from the expected output of the software application under test is called as Bug or Defect.
Both of the terms are in use today but bug is more popular than defect. Bugs can be find out at any stage during SDLC (Software development
Life Cycle), it could be at the designing phase (SRS or FRD documents), requirements gathering, development phase, testing phase, user
acceptance testing phase or even by the end user while using that application. Most of the bugs are expected to be logged during testing phase
before the application goes live (in the market). If any bug is missed during testing then this might cause huge loss to the business depending
on the severity of the bug. Bug does have its own life cycle from the point it is logged till the point it is closed. Here are the most important
stages in a bug life cycle in a diagrammatic representation:

BUG LIFE CYCLE Diagram:

Explanation of BUG Life Cycle:

During testing phase when a bug or defect is identified by test team or tester then that bug is logged into reporting portal such as
Assembla, JIRA, Bugzilla, etc. When a bug is logged into portal it has a default status as NEW.

Bug with NEW status is assigned to the development team which will look into the bug and decide whether the bug is valid or invalid. If
they found that bug is invalid then they will change the status to INVALID with a proper explanation. Test team will either reopen it or
close it based on the explanation given by the development team.

If bug is valid and accepted by the developers then status is changed to ASSIGNED and then team fixes the bug and assigns it back to
the testing team to verify whether the fix is working as expected or not. Here the status of BUG is changed to RESOLVED.

Further a bug which is fixed now can change its status to either VERIFIED or REOPENED, depending on whether the bug is fixed or re
producible.

When the bug is fixed successfully and application is behaving as expected, the status of that bug is changed from VERIFIED to
CLOSED. Sometimes to close the bug, it may require additional level of review; it could be project management team or business end
user.

If the bug fix didnt work as expected, then the test team may mark the status from RESOLVED to REOPENED after giving the
necessary reason for why it is still a bug.

After the bug is REOPENED, status changed to ASSIGNED again and development team will fix it according to the requirements and
send it again to the test team to verify.

Again if the bug fix worked as expected then test team will set it to VERIFIED and CLOSED. And if it still has some issues then cycle
goes on till the bug is in CLOSED state.

We may also note that if bug reported by test team or end user is unclear to any of the project team or team member then they may ask
for more information about the bug from required teams at any state of the bug life cycle.

Participants of BUG Life cycle:

BUG Reporter: One who identifies the bug is known as BUG reporter. Bug reporter validates the bug and enters the bug details into bug
reporting tools. It is his responsibility to put the correct subject, bug priority, application component, test environment (DEV, UAT, PROD),
bug assignee and bug description. When needed, he should attached required screenshots or data file to clarify the bug details.

BUG Tracking tool: Bug tracking is done by bug reporting tool like Assembla, JIRA, Bugzilla, etc. Here the life cycle of BUG with its
responsible bug group and bug details are tracked. This helps in preparing bug reports as well.

BUG Group: This is the group of people who can see the bug details. Always main participants are tester or end user who reported the
bug, developer to whom this bug is assigned, project manager and QA manager. Other optional member can be added into BUG group as
per the requirement of the project management.

BUG Owner: This is the responsible person who reviews and owns the bugs. A bug owner checks if the bug description is enough and it
is reproducible based on the given information, if not he may assign it back to the reporter asking them for more information. Based on
the priorities assigned to a bug this member takes the ownership to get the bug fixed and deliver the fix within the strict deadline of the
project.

Above listed are the main stages in a defect/bug life cycle.

I think I have addressed all major stages of Bug Life Cycle. Some companies may have more or less stages depending on their work culture. In
your company if you are using other than above important stages if any then please let us know in the comments below. I will keep on updating
the article for latest testing information.