Bug Life Cycle in Software Testing: Every Status, Who Owns It and Common Mistakes
From the moment a tester finds a defect to the moment it is verified and closed, a bug passes through a series of statuses. Learn what each one means, who is responsible at each step, and how to keep the process from becoming paperwork.
- The bug life cycle, or defect life cycle, is the set of statuses a defect moves through from discovery to closure.
- The core path is New → Assigned → Open → Fixed → Retest → Verified → Closed.
- Side paths handle bugs that are rejected, duplicated, deferred or that come back as Reopened.
- Exact names vary by team and tool. Clear ownership at each step matters more than the number of statuses.
A tester finds that the checkout total is wrong when a coupon and free shipping apply together. Without a shared process, that finding might live in a chat message, get fixed by someone, never get rechecked, and reappear in production a month later. The bug life cycle is the agreed path that makes sure every defect is recorded, decided on, fixed, verified and closed, with someone clearly responsible at each step.
This is a process guide, so it contains no code. The statuses below are the common ones used across the industry; your team’s tool may name them differently.
What is the bug life cycle?
The bug life cycle is the sequence of states a defect passes through in a tracking tool such as Jira, Azure DevOps, Linear or GitHub Issues. Each state answers one question: what is happening to this bug right now, and whose turn is it? It is narrower than the software testing life cycle (STLC), which covers the whole testing effort from planning to closure.
The main flow
New ──► Assigned ──► Open ──► Fixed ──► Retest ──► Verified ──► Closed
│ │
├─► Rejected └─► Reopened ──► Assigned
├─► Duplicate
└─► DeferredThe happy path runs left to right. The branches handle the many cases where a report turns out not to need a fix, needs to wait, or was not actually fixed.
Every status explained
| Status | Meaning | Usually owned by |
|---|---|---|
| New | Logged, not yet reviewed | Reporter (often a tester) |
| Assigned | Accepted and given to a developer | Lead or triage group |
| Open / In Progress | A developer is analysing or fixing it | Developer |
| Fixed / Resolved | A code change is ready, usually merged | Developer |
| Pending Retest | The fix is deployed to a test environment | Release or DevOps process |
| Retest | A tester is checking the fix | Tester |
| Verified | The fix works as expected | Tester |
| Closed | Done, nothing further needed | Tester or lead |
New
The bug has been reported with a title, steps to reproduce, expected and actual results, environment details and evidence such as screenshots or logs. Quality here decides how fast everything else moves. Our guide on how to write a bug report covers what to include.
Assigned and Open
After triage, someone accepts the bug and assigns it. The developer then opens it, reproduces it, finds the cause and works on the fix. If the developer cannot reproduce it, the bug goes back to the reporter for more information rather than sitting silently.
Fixed
The developer has changed the code, ideally adding an automated test that would have caught the bug, and marked it fixed. “Fixed” is a developer’s claim, not yet a confirmed fact. That is why the next steps exist.
Retest, Verified and Closed
Once the fix reaches a test environment, a tester repeats the original steps and checks related areas, since fixes often touch nearby behaviour. If it works, the bug is verified and closed. Some teams close straight from Retest; others keep Verified separate so that closing can wait until the fix ships to production.
Side paths
| Status | When it is used |
|---|---|
| Rejected / Not a bug | The behaviour is correct, matches the requirements, or was caused by misuse or a bad environment |
| Duplicate | The same problem is already reported; link to the original |
| Deferred / Postponed | Real, but will be fixed in a later release |
| Cannot reproduce | Nobody can make it happen with the information given |
| Need more information | Back with the reporter for details |
| Won’t fix | Real, but the cost of fixing is higher than its impact |
| Reopened | The fix did not work, or the bug returned |
Every rejection or “won’t fix” should include a short reason. “Works as designed, see requirement 4.2” helps the reporter learn and prevents the same bug being filed again next week. If testers disagree with a rejection, the conversation should involve whoever owns the requirement, not just tester and developer.
Who owns each step
- Tester or reporter: logs a clear, reproducible report, retests fixes, verifies and closes, and reopens with evidence if needed.
- Triage group: often a lead, product owner and senior developer, who decides validity, severity and priority, and assignment.
- Developer: reproduces, finds the root cause, fixes, adds a regression test and explains the change.
- Product owner: decides what is a bug versus a change in requirements, and approves deferrals.
The single most useful rule: every open bug has exactly one assignee at every moment. A bug “with the team” is a bug with nobody.
A worked example
- New: a tester reports “Order total ignores free shipping when a 10% coupon is applied”, with steps, a screenshot and the test account used.
- Triage: confirmed as valid. Severity is major, since customers are overcharged; priority is high. Assigned to the checkout developer.
- Open: the developer reproduces it and finds that the coupon calculation runs after the shipping rule and overwrites it.
- Fixed: the order of operations is corrected and a unit test is added covering coupon plus free shipping. The change is merged.
- Retest: after deployment to staging, the tester repeats the steps, then checks coupons without free shipping and free shipping without coupons.
- Reopened: the total is now right on the cart page but still wrong in the confirmation email, which uses a separate calculation. The tester reopens with evidence.
- Fixed again: the developer moves both screens to one shared calculation.
- Verified and Closed: both pages are correct, and the new test is part of the regression suite.
The reopen in step 6 is normal. It shows why verification by someone other than the developer catches problems that a single passing check would miss.
Triage: the step that makes or breaks the cycle
Triage is where new bugs are reviewed, usually in a short regular meeting or asynchronously. For each bug, decide: Is it valid? Is it a duplicate? How severe is it, and how urgent? Who owns it, and in which release will it be fixed? Without triage, bugs pile up in “New”, and the backlog becomes a list nobody trusts. A healthy rule is that no bug stays in New for more than a working day or two.
Tip: Agree on a “definition of fixed”: for example, a code change merged, a regression test added and the fix deployed to the test environment. A shared definition stops bugs bouncing between Fixed and Reopened because people meant different things.
Reopened bugs
A bug is reopened when the fix did not work, only fixed part of the problem, or the bug came back later. Reopen the original bug if it is the same problem, so the history stays in one place. If the retest reveals a different problem, log a new bug and link it. A high reopen rate usually points to fixes made without reproducing the bug first, missing regression tests, or unclear acceptance criteria. Bugs that come back intermittently may be timing problems, which our guide to flaky tests discusses.
The bug life cycle in Jira and other tools
Most trackers come with a default workflow, such as To Do, In Progress and Done, which is too simple for defects. Teams usually add a few statuses, such as In Review, Ready for QA and Reopened, and use resolution fields like “Duplicate” or “Won’t Do” rather than separate statuses for every outcome. Automation can help: moving a bug to Ready for QA when the linked pull request merges, or alerting when a critical bug has had no update for a day.
Designing your own workflow
- Keep it short. Every status must answer “whose turn is it?”. If two statuses have the same owner and next action, merge them.
- Make transitions clear. Document who can move a bug from each status, and what must be true first.
- Require reasons for Rejected, Won’t Fix and Deferred.
- Review deferred bugs each release, or they become permanent.
- Close the loop with the reporter, especially for bugs reported by customers or support.
Useful metrics
| Metric | What it tells you |
|---|---|
| Open bugs by severity | Current risk |
| Time in each status | Where bugs get stuck |
| Time to fix critical bugs | Responsiveness where it matters |
| Reopen rate | Quality of fixes and verification |
| Rejected rate | Quality of reports or clarity of requirements |
| Escaped defects | Bugs found in production that testing missed |
Use these to improve the process, not to rank individuals. Counting bugs found per tester, or bugs caused per developer, quickly encourages people to game the numbers.
Final thoughts
The bug life cycle is simply an agreement about what happens to a defect and who is responsible next. Keep the statuses few and meaningful, triage quickly, require independent verification, and give a reason whenever a bug is not fixed. Done well, it turns bug tracking from a list of complaints into a reliable path from problem to fix.
Frequently asked questions
What is the bug life cycle?
It is the set of statuses a defect moves through, typically New, Assigned, Open, Fixed, Retest, Verified and Closed, with side paths such as Rejected, Duplicate, Deferred and Reopened.
What is the difference between bug life cycle and STLC?
The bug life cycle tracks a single defect from report to closure. The software testing life cycle covers the whole testing process, from planning and design to execution and closure.
When is a bug reopened?
When retesting shows the fix did not work, only partly worked, or the same bug returns later. A different problem found during retesting should be logged as a new bug.
What does deferred mean for a bug?
The bug is valid but will be fixed in a later release, usually because it is low priority or risky to change now. Deferred bugs should be reviewed every release.
Who closes a bug?
Usually the tester who verified the fix, or a lead. Closing after independent verification confirms the fix works, rather than relying on the developer’s report alone.
Keep learning
Need help with testing, WordPress or SEO?
We help teams ship better software and grow their sites. Tell us what you are working on and we will suggest a clear next step.