Bug Life Cycle

Why teams track a bug’s status

A small team with five bugs could keep them in their heads. A real team has hundreds of open bugs, several developers, a few testers, a product owner and a release date. Without statuses, three things go wrong very quickly:

• Bugs get forgotten. Someone says “I’ll look at it”, goes on holiday, and nobody notices the bug never moved.
• Nobody knows what is safe to release. Is the checkout bug fixed? Fixed and checked? In which build?
• Work gets done twice, or not at all. Two developers fix the same bug while a third bug sits untouched.

A status answers one simple question for everyone: who has to do what next? It also gives the team a history: when the bug was found, who touched it, how long each step took, and how many times it came back.

The statuses, one by one

Here is a typical workflow. The color shows who usually moves the bug forward.

New

You’ve just filed the report. It’s in the queue, but nobody has confirmed it yet. Before you press Create, the quality of your report decides how fast it moves on: clear steps, exact environmentEnvironmentA setup of servers, data and configuration where the software runs, such as dev, staging or production.Open in glossary →, evidence. See How to Write a Bug Report.

Triaged / Open

Someone (a QA lead, a team lead, the product owner, or the whole team in a triage meeting) reviews the bug and decides three things: Is it real? Is it new? How urgent is it? They confirm or adjust the severity you proposed and set the priority. If it passes, it becomes Open (some tools call this Confirmed, Accepted or To Do).

Assigned

A developer is named as the owner. Some teams skip this status and simply fill the Assignee field while the bug is Open.

In Progress

The developer is actively working on it: reproducing it, finding the root cause, writing and reviewing the fix. This is when they may ask you questions in comments. Answer quickly, because a waiting developer often switches to something else.

Fixed / Resolved

The code change is done, reviewed and merged. Important: it is not verified yet. It only means the developer believes the bug is gone. In many tools the developer also fills in a Fix version (which build or release contains the fix).

Ready for test

The fix is now in a build that testers can install: a new stagingStagingA pre-release environment that mirrors production as closely as possible.Open in glossary → deploy for a website, or a new TestFlightTestFlightApple's service for distributing beta builds of iOS apps to testers before App Store release.Open in glossary → or internal build for a mobile app. The bug is assigned back to QA. Some teams call this Retest, In QA or Ready for QA, and some merge it with Fixed.

Verified / Closed

You retested the bug and it’s gone. Verified means QA has confirmed the fix. Closed means the team is finished with it, often when the release containing the fix ships. Many teams use only one of the two.

Reopened

The retest failed, or the bug came back later. The ticket goes back to the developer, with a comment that says exactly which build you tested and what still happens. A bug can be reopened more than once.

Who moves the bug

Who	Typical moves
Tester	Creates it (New); moves Ready for test → Verified or Reopened; adds missing details after “Cannot reproduce”
QA lead / team lead / PO	New → Open (triage); sets priority; assigns; decides Duplicate, Won’t fix, Deferred
Developer	Assigned → In Progress → Fixed → Ready for test; may resolve as Cannot reproduce or Not a bug
Release / CI tools	Some teams move bugs to Closed automatically when the release ships

The side exits

Not every bug ends with “Fixed”. These outcomes are normal and don’t mean you did a bad job.

DuplicateNot a bugWon't fixCannot reproduceDeferred

Duplicate. The same bug is already reported. Your ticket is linked to the original and closed. A duplicate bugDuplicate bugA bug report that describes a bug someone already reported.Open in glossary → wastes time, so search the tracker before filing.

Who decides: usually the lead in triage, sometimes the developer.

What you do: if your report adds something new (another device, a clearer recording), copy it into the original ticket as a comment. If you think it was closed wrongly (“same symptom, different cause or platform”), explain the difference politely and ask for it to be reopened.

Not a bug (also Rejected, Works as designed, Invalid). The app does what it was designed to do, or the report is based on a misunderstanding.

Who decides: the developer or lead, ideally checked against the requirement.

What you do: read the reason and check the requirementRequirementA statement of what the software must do or how well it must do it.Open in glossary → or acceptance criteriaAcceptance criteriaConditions a user story must meet to be considered done and accepted.Open in glossary →. If the requirement agrees with the developer, accept it gracefully. If the requirement is unclear or you think users will be confused, bring it to the product owner. That’s not a bug fight; it’s a question about what the product should do.

Won’t fix (also Won’t do). It’s a real bug, but the team decided not to fix it: it’s too rare, too expensive to fix, or the feature is being removed next month.

Who decides: the product owner or lead. It’s a business decision.

What you do: make sure the reason is written in the ticket, then let it go. If new facts appear later (more users affected, a customer complaint), you can raise it again.

Cannot reproduce (also Works for me). The developer followed your steps and didn’t see the bug.

Who decides: the developer.

What you do: see Handling “Cannot reproduce” below. In short: find what’s different between your setup and theirs, and add it.

Deferred (also Backlog, Postponed, Later). A real bug that will be fixed, just not now, usually because other work is more urgent before the release.

Who decides: the product owner or lead.

What you do: check that the ticket says why and until when (for example “after the 5.0 release”). Deferred bugs with a known workaroundWorkaroundAnother way for users to reach their goal while a bug is still unfixed.Open in glossary → often go into the release notesRelease notesA short list of what changed, what was fixed and the known issues in a build.Open in glossary → as known issues.

Status vs resolution

This confuses many beginners, so let’s be precise. Many trackers, including Jira, have two separate fields:

• Status: where the bug is in the workflow right now. Example: Open, In Progress, Closed.
• Resolution: why the work ended. Example: Fixed, Duplicate, Won’t fix, Cannot reproduce. While the bug is still being worked on, the resolution is empty (Jira shows it as Unresolved).

Status	Resolution	What it means
In Progress	Unresolved	Someone is working on it
Closed	Fixed	Fixed and verified
Closed	Duplicate	Closed because another ticket covers it
Closed	Won’t fix	Real bug, deliberately left
Resolved	Cannot reproduce	Waiting for more info, or for someone to close it

Triage meetings

Triage comes from emergency medicine: deciding which patients need help first. In bug triage, a small group reviews new bugs and decides what happens to each one.

• Who: usually a QA lead or tester, a developer or tech lead, and the product owner (the person who decides priorities).
• How often: from daily (just before a big release) to once or twice a week. Some teams triage asynchronously in the tracker instead of meeting.
• What they decide for each bug: Is it valid? Is it a duplicate? What are the severity and priority? Who fixes it, and in which sprintSprintA short, fixed period (often two weeks) in which a team builds and tests a set of work.Open in glossary → or release? Does it need more information?

How severity and priority are decided is a whole topic of its own: see Severity vs Priority.

How it looks in Jira

JiraJiraA popular tool for tracking bugs, user stories and tasks.Open in glossary → is the most common tracker you’ll meet, so it’s worth knowing how it handles all this. Working with Jira covers the tool in more depth.

• Workflows differ per team. A Jira workflow is the set of statuses and allowed transitions for a project. Every company configures its own. Team-managed projects often start with just To Do → In Progress → Done. Older company-managed projects often use Open → In Progress → Resolved → Closed, with Reopened. Many QA teams add Ready for test or In QA.
• Status categories. Whatever the names, Jira groups every status into three categories with fixed colors: To Do (grey), In Progress (blue) and Done (green). That’s why a status lozenge’s color tells you more than its name.
• Transitions are buttons. You don’t type a status; you click the status button on the ticket and choose an allowed next step, like Ready for test → Verified. Some transitions open a screen asking for a resolution or a comment.
• The Resolution field is set when a bug reaches a Done status. Typical values are Done or Fixed, Won’t Do, Duplicate and Cannot Reproduce, but teams can change them.
• History. The History tab under Activity shows every field change with who and when. It’s the life cycle of that bug, written down.

Handy searches (JQL) for a tester:

-- Bugs waiting for me to retest
project = SHOP AND type = Bug AND status = "Ready for test" AND assignee = currentUser()

-- Every unresolved bug I reported
type = Bug AND reporter = currentUser() AND resolution = Unresolved

-- Bugs that were reopened in the last 30 days
type = Bug AND status CHANGED TO "Reopened" AFTER -30d

What testers do at “Ready for test”

This is the moment you own the bug again, and it’s where good testers stand out. You are doing two different things here:

• RetestingRetestingRunning the same test again to confirm that a reported bug is really fixed.Open in glossary →: repeating the original steps to confirm this bug is gone.
• Regression testingRegression testingRe-running tests to check that new changes didn't break things that used to work.Open in glossary → around the fix: checking that the change didn’t break anything nearby.

When a retest fails, reopen the bug with the build you tested, what still happens, and new evidence. If the original bug is fixed but you found a different problem, file a new bug and link it instead of reopening.

Handling “Cannot reproduce”

A “Cannot reproduce” result is not an insult. It usually means one detail is missing from the report.

If you can’t reproduce it either, say so honestly. Note how often you tried, and keep an eye out for it. Intermittent bugs are often caused by timing, such as a race conditionRace conditionA bug that depends on the timing or order of events, so it only happens sometimes.Open in glossary →.

Handling “Not a bug”

• Point to the source of truth: the requirement, the design, platform guidelines, or how similar screens behave.
• Separate the bug from the opinion. “This doesn’t match AC 3” is a bug. “I think this is confusing” is valid feedback, but it’s a product decision.
• Let the product owner decide if you and the developer disagree. Then accept the decision.

There’s an interview question about exactly this: see What do you do when a developer says it’s not a bug?.

Metrics teams track

Because every status change is recorded, teams can measure how bugs flow. Two numbers you’ll hear about often:

• Reopen rate: the share of fixed bugs that fail retest or come back. A high reopen rate suggests fixes are rushed or retests are too narrow. It’s a team signal, not a score for one developer.
• Bug aging: how long bugs stay open, often shown as “open bugs older than 30 days”. Old bugs are a sign of a growing backlog, or of bugs nobody will ever fix (which should then be closed as Won’t fix, honestly).

Others you may see: time from New to triage, time to fix by priority, and the number of open critical bugs before a release.