JIRA Bug Life Cycle

JIRA bug life cycle is also known as a defect life cycle. The bug life cycle consists of a set of states that a bug goes through. The
number of states that the bug goes through varies from project to project. We can define the bug as an error, flaw or we can say
that when the actual output does not match with the expected output, it is known as bug or defect. Both the terms, i.e., bug and
defect are commonly used but the most popular is a bug. A bug can be generated at any stage of the SDLC (Software Development
Life Cycle), it could exist in requirements gathering, designing phase where SRS document is designed, development phase, testing
phase or user acceptance testing done by the end-user at the time of using the application.

A bug has its life cycle from the point when the bug is logged in to the point the bug is closed. Bug undergoes the following states:

o New
o Assigned
o Open
o Fixed
o Retesting
o Reopen
o Verified
o Closed

New
During the time of the testing phase, the bug or defect is identified by the tester and it is logged in to the bug tracking tool such as
Jira, Bugzilla, etc. The bug which is detected by the tester will be posted for the first time in a bug tracking tool. This status is
assigned as a New status.

Assigned
Bug with New status is assigned to the software developers and they will look into the bug to check whether the bug is valid or
invalid. If the bug is invalid then they change the status to invalid. If the bug is valid then the status is changed to assigned then the
software developers start working on the defect to get fixed.

Open
When the bug is assigned to the software developers then they start analyzing on it and works on the defect fix. The bug or defect
can be opened in three stages:

o Duplicate
If the defect is repeated twice or the defect corresponds to the same concept of the previous bug, then it changes the status
to duplicate.
o Rejected
If the developer feels that the defect is not a genuine defect, then it changes the status to Rejected.
 o Deferred
If the bug is not of higher priority and can be solved in the next release, then the status changes to Deferred. The deferred
state is also known as postpone state.

Fixed
When a developer makes a necessary code changes and verifies the change, then he/she can make the bug status as fixed. When
the bug is fixed by the developers then the status is changed to either Reopened or Verified.

Retest
Once the bug is fixed by the software developers then it is assigned back to the testing team to check whether the bug has been
fixed or not.

Reopen
If the bug persists even after the developer has fixed the bug, then tester changes the status to Reopen and once again bug goes
through the whole bug life cycle.

Verified
The tester retests the bug after it got fixed by the developer if no bug found then it changes the status to Verified.

Closed
If the bug is no longer exists, then it changes the status to Closed.

Participants of Bug life cycle

o Bug Reporter
The person who identifies the bug is known as Bug Reporter. Bug reporter validates the bug and enters all the bug related
details into the bug tracking tool such as correct subject, bug priority, application component, test environment, bug
assignee, bug description. When required, the tester needs to send the attached screenshot to clarify the bug details.
o Bug tracking tool
A bug can be logged in to the bug tracking tool and bug tracking tool can be Jira, Bugzilla, Assembla, etc.
o Bug Group
Bug Group is a group of people who can see the bug details. Bug Group can include tester or end user who reported the
bug, the developers to whom the bug is assigned, project manager, QA manager.
o Bug Owner
Bug owner is the person who reviews and owns the bug. Bug owner checks whether the bug information is sufficient or not,
if not then the bug is assigned back to the bug reporter to provide more information. Based on the priorities given to the
bug, Bug owner takes the ownership of the bug and get fixed it within the deadline.

What Is a Bug Life Cycle? #bug life cycle A bug life cycle in software testing is a set of statuses designed to coordinate defect management. A bug status helps
keep all the members of the development team posted on the progress. The cycle starts when a QA engineer reports a new issue found in the tested
software and finishes when this issue is sold. Stages of Bug Life Cycle in Testing A defect life cycle can consist of different stages depending on a company’s
practices. Available defect management tools, number of team members, and adopted methodologies are among the things that can impact the workflow
and, thus, a variety of bug life cycle stages. Below, you will find information about the frequently used statuses that designate different stages of the defect
management process. Some of them are mandatory and some are optional, used to provide more details about the progress. NEW Let’s say a software
tester starts inspecting a product and finds a bug. What’s next? A specialist logs the defect into a tracking system, describing the steps for reproducing,
environment details (OS, device, browser), and severity. The defect is assigned the New status. How to Write a Bug Report: a Brief Guideline ASSIGNED A
project manager, team lead, or developer in charge reviews the report. They check whether the bug is valid. If yes, they choose a developer to fix the defect.
The choice might depend on the type of the bug (e.g., front-end or back-end, coded in PHP or Python, etc.) and available resources (who has enough time
and expertise to solve the problem). The bug goes to the Assigned status. OPENED A developer who is to fix the issue sets the Opened status and starts
analyzing the problem. A closer look at the defect may reveal some pitfalls. Thus, instead of fixing the bug, a developer has to change the status to one of
the following: Duplicate — the identical problem was already reported. Rejected — the bug is not reproducible; a developer can’t understand the problem
due to the ambiguous wording; there are no clear requirements; a QA engineer misunderstood the requirements; improper environment configuration
during testing, etc. Deferred — the issue is not urgent and can be fixed later. Not a bug — the problem does not affect software functionality (e.g., a
suggestion to change a font or background color). Cannot be fixed — for some reason, this bug has to become a feature, as there is no way to fix it (for now
or at all). Need more info — a developer needs extra information about the defect to find its root cause. If the problem is reproducible and obvious, the
developer starts working on fixing it. FIXED As soon as the developer makes changes to the code, the bug goes to Fixed. RETEST The task returns to the QA
specialist, who checks if the problem is actually solved. REOPENED If a software tester discovers that it is still possible to reproduce the bug, they Reopen it.
A developer looks into the problems once more. The task goes from Fixed to Retest to Reopened until the defect no longer exists. VERIFIED If a QA specialist
confirms that the bug has been fixed, the status changes to Verified. CLOSED Closed is a status that marks the final stage of the bug life cycle. The work is
done. Participants of a Bug Life Cycle There are two main participants in the bug life cycle — a software tester and a developer. One finds and logs the bug,
and the other fixes it. In bigger teams, however, other specialists get involved in the defect management process. When it comes to defining bug severity
and priority, also known as bug triage, someone has to evaluate and prioritize the defects. The person in charge of prioritization discusses the particularities
of defects with other team members. All the people involved in this process are known as the defect triage committee. The process can go like this: A Test
Lead or QA Engineer determines bug severity. A Development Team Lead assesses the potential risks. A Project Manager decides on bug priority and
discusses the deadlines for fixing. A Development Team Lead assigns the task to a developer and sets deadlines. Again, the exact workflow depends on the
team structure and processes. In big companies, Department Heads and CTO can be involved in the discussion, too.

Source: What Is a Bug Life Cycle? - QA Madness Software testing company

The Example of a Bug Life Cycle New. A QA engineer (let’s call him Bob) goes to the website of an online bookstore he is testing and adds a book to a cart.
The item appears in the cart, but Bob can’t order two of the same books. A click on “+” to change the number of items doesn’t actually change it. Bob
describes the problem and logs a bug as New. Assigned. A PM (let’s suppose this is Susie, and she’s in charge of delegating the tasks) sees a bug on the list.
The problem appears to be valid and serious. Susie assigns the task to a back-end developer, Alex, who coded the cart functionality. Open. Alex sees a new
task and tries to reproduce it following the instructions in the report. Indeed, the “+” doesn’t work as intended. Alex changes the bug status to Open and
starts looking for the root cause. Sometimes, however, things don’t go this way. Alex knows that bug can be invalid. In this case, instead of marking the
defect as Open and trying to fix it straight away, he can use a different status, for example: Duplicate. When studying the report, Alex realizes that Sam,
another software tester, logged this bug yesterday. Alex marks the bug as Duplicate. There is no need to add it to the pull of tasks once more — it is already
there. Rejected. Using the instructions from the bug report, Alex adds the book to the cart and clicks on “+.” The number of items changes to two. How’s
that possible? Maybe an unstable internet connection caused the problem. Or maybe, the defect appears on a specific device, but Bob forgot to include this
information in the description. Deferred. The bug occurs only on the Firefox browser, which has a small share among users. Alex decides to fix it later, after
figuring out a more critical problem: why the payments fail. skills of the test team members. Not a bug. Alex is concerned at first, but then he realizes that
Bob tried to buy an extra ebook. It’s impossible because of the website logic: a user can access an ebook from any device, there’s no need to buy it twice.
Need more info. Alex does not understand under what circumstances the bug appears. Is a user logged in or not? Is Bob trying to add an item on a product
page or at the stage of order confirmation? Cannot be fixed. Alex is aware of this problem and has tried to solve it more than once. It is a hard-to-find bug,
and he needs to review a huge codebase to fix it. At the moment, a user can order two books by typing the number “2” into the box displaying the number
of items. It’ll do for now. Fixed. Alex finds a mistake in the code and fixes it. The status goes to Fixed. Retest. Bob receives a notification about the status
change. He needs to check the functionality once more and make sure users can change the number of books now. He sets the Retest status and starts
working. Reopened. Unfortunately, during the retesting, Bob discovers that the bug still occurs. A click on “+” does not change the number of items. The task
goes back to Alex under Reopened status. Alex needs to look into the problem once more. The bug will go through the Fixed and Retest stages again.
Verified. During the testing, Bob makes sure that the button works as expected. Now, a user can change the number of items in the cart using “+”. Bob
changes the defect status to Verified. Closed. Susie sees that the problem is solved and closes the task.

Source: What Is a Bug Life Cycle? - QA Madness Software testing company