← back to the section

A filed bug report doesn't disappear or get fixed instantly — it goes through a journey: someone looks at it, picks it up, fixes it, checks it, closes it. This journey is called the bug lifecycle, and its stages are called statuses. It all lives in a bug tracker — a tool where the team manages tasks and defects (the most widely known is Jira).

Understanding the lifecycle and statuses lets you speak the same language as the team and always know what stage your bug is at and what is expected of you right now.

whose turn is it: until you re-test, the bug is not closed Rejected · Duplicate · Cannot Reproduce never gets fixed Open you filed it In Progress being fixed Fixed "fixed it" Closed bug is gone Reopened — back to the developer Fixed is your move: the developer only claims the fix is done

The usual path is Open → In Progress → Fixed → Closed, but after Fixed the move is yours: if the bug is still there, Reopened sends it back to the developer, and the loop can repeat more than once. Some bugs never reach the work at all: Rejected, Duplicate, Cannot Reproduce.

Common bug statuses

Names vary a little from team to team, but the logic is the same:

  • Open / New. You filed the bug and no one has picked it up yet.
  • In Progress. The developer picked up the bug and is working on it.
  • Fixed / Resolved. The developer says "fixed" and hands it to you for re-test. Note: this is not the end — it is a signal for you to re-test.
  • Closed. You re-tested and the bug is gone — the defect is closed. This is the end.
  • Reopened. You re-tested but the bug is still there (or came back) — you reopen it and return it to the developer.

There are also "rejection" statuses, when the bug will not be fixed:

  • Rejected / Won't Fix. The team decided this is not a bug, or it is not worth fixing.
  • Duplicate. This bug was already filed by someone else.
  • Cannot Reproduce. The bug could not be reproduced following your steps — usually because of an incomplete report.

How a bug moves through the cycle

The typical path: you file it (Open) → the developer picks it up (In Progress) → fixes it (Fixed) → you re-test. Then a fork: it's gone — Closed; it's still there — Reopened, and it goes back to the developer. This can repeat more than once.

Two important points:

  • Fixed is your turn to act, not the end. The developer has only claimed it is fixed. Until you re-test and close it yourself, the bug is not closed. Testing a fixed bug is called re-test.
  • After re-testing the bug, check what's around it. The fix may have broken something nearby — this is called regression. "The bug is gone, but something else broke" is a common story.

Defect triage: who decides a bug's fate

Between "filed" and "picked up" there is a step the status list doesn't show. A week produces more bugs than the team can fix before the release, and somebody has to decide what gets fixed now, what later, and what never gets fixed at all. That short regular meeting is called defect triage.

Three people usually sit in it. The tester explains the finding and answers questions — what exactly breaks and how often. The developer or team lead estimates what the fix costs and what it might disturb. The manager or product owner says what it means for customers. For every new bug four things are decided: whether it is a real defect (otherwise Rejected or Duplicate), which release it belongs to, who will take it, and with what priority.

Setting the priority is part of triage but not triage itself. Priority is set per bug, from the properties of that bug: how badly it breaks and how many customers are hit. Triage looks at all the bugs at once and adds what a single card cannot show: how many hands the team has before the release, what gets fixed first among equal priorities, and what is knowingly left until next time. That is why "high priority" and "fixed in this release" are two different decisions, and the second one is made together.

What is a bug tracker

A bug tracker (or task tracker) is a system where the team stores all tasks and bugs: who filed it, who is responsible, status, priority, change history, comments, and attachments. Everything in one place and nothing gets lost. The most widely used is Jira; others exist (YouTrack, Azure DevOps, GitLab Issues, Trello, etc.), but the logic is similar everywhere.

In a tracker you will:

  • File bugs — essentially creating a bug report as a card.
  • See your own tasks and others' — what is in progress, what is waiting for re-test.
  • Change statuses — moving a bug to Closed or Reopened after re-testing.
  • Communicate in comments — clarify things with the developer, answer questions.
  • Filter and search — for example, "all open bugs with high priority in my project."

Worth noting separately: a bug and a regular task (new feature) follow a similar path in the tracker, but a bug is about "something is broken" while a task is about "something needs to be built." Bugs are often linked to the feature or sprint where they were found.

Where this applies

The tracker is your main workspace. A tester's workday is largely made up of actions in it: file a bug, move a verified fix to Closed, reopen one that wasn't actually fixed, reply to a comment, check what is left before the release. Understanding the statuses means you never lose track of a bug and always know whose turn it is — yours or the developer's.

Where people stumble most often:

  • They think Fixed means they can relax. No — it's a signal to re-test. Until you close it yourself, the bug is not closed.
  • They close the bug without checking nearby (regression) — and miss something the fix broke.
  • They reopen a bug silently without explanation. Always write in the comments what is still wrong and which steps show it — otherwise the developer won't be able to reproduce it again.
  • They file duplicates without searching first to see if the bug already exists.

In short

  • The bug lifecycle is a sequence of statuses: Open, In Progress, Fixed, Closed — and Reopened when the re-test fails, which starts the loop again.
  • Fixed is not the end but your move: the developer only claims the fix is done; until you re-test and close it, the bug is open.
  • The refusal statuses are Rejected, Duplicate and Cannot Reproduce: the bug is closed without a fix, and the last one almost always means an incomplete report.
  • Defect triage decides four things per bug: is it a real defect, which release it goes into, who takes it and at what priority.
  • Priority is set from the properties of one bug; triage looks at all bugs at once and at the hands available before the release — which is why "high priority" and "fixed in this release" are two different decisions.
  • After verifying a fix, look around it: a fix often breaks something nearby, and that is a regression.