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.

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 for beginners:

  • 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.

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 beginners stumble:

  • 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.

What to learn next. Bugs are covered. Next come the tools that speed up day-to-day work. Start with test management tools where test cases and runs are kept, then move on to browser DevTools.