What Is the Bug Life Cycle? A Step-by-Step Guide for QA Teams

What Is a Bug?

A bug is software behaving in a way it was not designed to, caused by anything from a misread requirement to a missing line of code. QA teams also call bugs "defects", and this guide uses the terms interchangeably.

Bugs can enter at any point in the Software Development Life Cycle, and dynamic testing only catches the ones that fail at runtime.

What Is a Bug Life Cycle?

The bug life cycle, also called the defect life cycle, is the workflow a defect follows from discovery to closure. It starts the moment a tester logs the issue and ends only when a verifier confirms the fix and the defect cannot reproduce. Each state in the cycle has a specific owner, a defined entry condition, and a defined exit condition, which is what makes the cycle auditable.

Bug Life Cycle vs Bug Tracking Life Cycle

Three related terms get used interchangeably and shouldn't be. They describe different scopes.

• Bug life cycle (or defect life cycle): The workflow states a single defect moves through, from New to Closed. Scope: one bug, owned by tester and developer, governed by a state machine.
• Bug tracking life cycle: The tooling-level pipeline that surrounds the bug life cycle: how bugs are logged into a tracker, how triage filters the queue, how reports surface aging bugs, how analytics roll up trends, and how closed bugs are archived for compliance. Scope: the bug-tracker as a system, owned by QA leadership.
• Bug report life cycle: The lifecycle of the report itself as a document, from draft to enriched (with logs, video, screenshots) to closed and audited. Scope: one ticket as a record, owned by the tester.

In short, the bug life cycle is the workflow, the bug tracking life cycle is the platform that runs it, and the bug report life cycle is the artifact it produces. The rest of this guide focuses on the bug life cycle proper, with the tracking-level concerns covered in the continuous improvement section.

Stages of Bug Life Cycle in Testing

The stages of the bug life cycle walk a defect from discovery to closure. Below are the 9 core states every team uses, followed by 7 additional states that handle edge cases. Tool conventions vary (Jira calls "Open" "In Progress"; some teams collapse Pending Retest into Retest) but the workflow logic is the same.

Phases vs Stages

Some teams describe the bug life cycle in phases, others in stages; the terms are used interchangeably. A common grouping bundles the 9 stages into 3 phases:

• Detection phase: New, Assigned (the defect is captured and routed).
• Resolution phase: Open, Fixed, Pending Retest (the developer owns the work and ships a fix).
• Verification phase: Retest, Reopened, Verified, Closed (QA confirms the fix and the regression check is clean).

Phases are useful for high-level reporting ("how many bugs are in the resolution phase this sprint?"); stages are what the tracker actually transitions through.

1. New

The first state in the cycle. The tester finds an issue during software testing, captures reproduction steps, environment details, and severity, and logs the report. New means "discovered and documented, but no developer has looked at it yet."

2. Assigned

The test lead or triage committee approves the report and assigns it to a developer or development team. The bug now has a named owner and a target sprint.

3. Open

The developer accepts the bug, reproduces it locally, and begins root-cause analysis. If during this stage the developer determines the report is invalid, a duplicate, or not worth fixing now, the bug moves to one of the alternate states (Rejected, Duplicate, Deferred) instead of progressing.

4. Fixed

The developer has changed the code, run unit tests, and pushed the fix to a build the tester can validate. Fixed is a developer-side state; the QA team has not yet confirmed the resolution.

5. Pending Retest

The fix is ready but the tester has not yet started validating it. Common reason: the build is queued behind other regression work. Tracking this state separately is useful because it surfaces fixes that are stuck waiting on test capacity, not on code.

6. Retest

The tester runs the original reproduction steps against the new build. The job is twofold: confirm the original bug no longer reproduces, and confirm the fix did not break adjacent functionality. Retesting and regression testing are different passes and should both run before close.

7. Reopened

During Retest the tester finds the bug still reproduces, or a new bug surfaced because of the fix. The bug returns to Open and the cycle repeats. Repeated Reopens for the same bug are a strong signal that the root cause is not yet understood; consider a code review with senior engineers before the next attempt.

8. Verified

Retest passed. The tester confirms the bug is resolved on the target build and the regression check is clean. For a defect that first surfaced in a specific browser, that confirmation should cover every affected browser, not only the one the fix was coded in, which is where confirmation testing across browsers comes in.

9. Closed

The release or project manager marks the bug Closed once it has shipped in a release or is confirmed resolved in production. Closed is the only terminal state for a successful fix; it locks the audit trail and removes the bug from the active queue.

Additional States

Defects do not always follow the happy path. Seven additional states handle the edge cases:

• Rejected: The developer (or triage) determined the report is invalid. The behavior is by design, the reporter misread the spec, or the report lacks reproduction steps.
• Duplicate: The bug already exists in the tracker as another open ticket. The duplicate is linked to the original and closed.
• Deferred: Valid bug but fixing it costs more than the business impact, or it depends on work scheduled for a later release. Kept in the backlog, not closed.
• Not a Bug: The behavior matches the specification. The reporter expected something different; the spec, not the code, is the source of confusion.
• Non-Reproducible: Developer cannot reproduce the issue with the steps provided. Common causes: environment mismatch, missing data, or a race condition the reporter encountered once.
• Cannot Be Fixed: The defect is real but is blocked by a third-party dependency, a hardware limitation, or a fundamental architecture constraint. Tracked separately so it surfaces in long-term planning.
• Need More Information: The developer cannot proceed because the report is missing logs, screenshots, build numbers, or steps. The bug bounces back to the tester until the gap is filled.

Workflow Participants

The cycle is owned by two main roles, the tester and the developer, but a healthy workflow names four to six participants so handoffs are unambiguous:

• Tester or QA Engineer: Discovers the bug, writes the report, assigns initial severity, and verifies the fix at Retest.
• Test Lead: Reviews logged bugs for accuracy, adjusts severity, and feeds the triage queue.
• Triage Committee: Usually a Test Lead, a Dev Lead, and a Product Owner. Sets priority, decides Defer vs Fix, and schedules the work.
• Developer: Reproduces the bug, fixes the code, runs unit tests, and moves the bug to Fixed.
• Dev Lead: Assigns bugs to specific developers, reviews the fix, and ensures the regression risk is low.
• Project Manager or Release Manager: Owns the closure gate. Tracks open P1/P2 counts against the release date and surfaces blockers to leadership.

In larger organizations, a Department Head or CTO joins the triage call for P1 defects that touch compliance, security, or customer-impact thresholds. The principle stays the same: every state transition has a named owner, and the tool enforces the handoff. Defect management and bug triaging guides cover the responsibilities in more depth.

Severity vs Priority vs Status

Most bug reports carry three labels that get confused with each other. Status is where the bug sits in the life cycle (New, Open, Fixed, Closed). Severity measures how badly the defect affects the application. Priority measures how urgently the team must fix it. A login outage on production is High severity and P1 priority. A typo in a footer is Low severity but can still be P1 priority if it is the company name on the homepage.

The two scales decouple because the business impact of a defect is not always proportional to its technical impact. A crash that affects 0.1% of users may be S1 severity but only P2 priority because the fix carries high regression risk. Triage assigns priority; the tester assigns severity at log time.

P1, P2, P3 Classification

• P1 (Critical or Blocker): Stops core functionality, blocks release, or causes data loss. Examples: checkout fails for all users, login page returns 500, payment double-charges. Fix before next deploy, no exceptions.
• P2 (High): Major feature impaired but a workaround exists. Examples: search returns wrong results on Safari but works on Chrome, password reset email delayed by 10 minutes. Fix in the current sprint.
• P3 (Medium or Low): Cosmetic issues, edge-case bugs, low-traffic browser quirks, minor UX inconsistencies. Schedule in a future sprint or mark as Deferred if the cost of the fix exceeds the value.

Some teams add P0 (production-down, all-hands incident) above P1. Whichever scheme you use, the rule is to write the definitions into the team's testing charter so every triager applies them the same way.

Challenges in the Bug Life Cycle

Even a well-defined cycle hits friction. The patterns below show up in nearly every team, regardless of size or tooling. Recognizing them is half the fix.

• Stalled handoffs: Bugs sit in Pending Retest for days because no one owns the build promotion. The result: critical fixes age while waiting on test capacity, not on engineering work.
• Inconsistent priority labels: Without a written P1-P3 definition every triager applies a different bar, and the queue drifts. One person's P2 is another's P1, and the release-blocker conversation gets noisy.
• Workflow rigidity: A heavyweight workflow forces a 5-person team to act like a 50-person team. Mandatory Pending Retest and dual-approval Closed transitions create overhead that does not pay back in small teams.
• Flaky tests masquerading as bugs: Tests that fail intermittently flood the New queue and crowd out real defects. QA wastes hours triaging false positives while genuine bugs age in the backlog.
• Limited visibility into status trends: Without dashboards the team only knows the open count, not whether it is growing or shrinking. By the time leadership notices the trend, the release is already off track.
• Environment mismatch in non-reproducible bugs: A bug reported on a tester's machine cannot be reproduced on the developer's, and the report bounces between Non-Reproducible and Need More Information. The bug is real but never fixed because the environment is never shared.

Best Practices for Defect Life Cycle Management

Below are the practices that fix the failure modes above. They are cheap to adopt and compound across sprints.

• Document the workflow in a shared playbook. Every state has a definition, an owner, and an entry-exit condition. New hires onboard from the playbook, not from word of mouth.
• Enforce reproduction steps before Assigned. The triage queue rejects reports missing the steps, environment, expected-vs-actual, or a visual attachment (screenshot or session video). This pushes quality back to the source. See our advanced guide on writing a bug report for the full template.
• Attach session artifacts at log time, not after. Video and console logs are 10x easier to capture during the test session than to recreate. Cloud test platforms attach them automatically.
• Run regression as part of Retest, not after Verified. The fix is most likely to break something in the same commit that introduced it; check before, not after, close.
• Review long-lived bugs monthly. Anything older than 30 days in Open is either misclassified, blocked, or should be Deferred. Stale bugs cost cognitive overhead without value.
• Tie test cases to bugs. When Verified, link the test case that caught the bug to the bug ticket. Future regression of the same area becomes a one-click rerun.

Critical Bug Criteria to Keep in Mind

Not every bug deserves a P1 ticket and an all-hands page. A working life cycle relies on team-wide agreement about what crosses the bar for "critical." The criteria below are what most engineering teams use to decide whether a defect deserves emergency handling, in rough order of weight.

• Customer-blocking impact: The bug prevents a user from completing a core action (login, checkout, file save, message send). If even a small percentage of users hit it, it is critical.
• Data loss or corruption: A bug that loses, duplicates, or silently corrupts user data is always critical, even if only one user is affected. The trust cost outweighs the volume.
• Compliance or security exposure: PII leaks, OWASP Top 10 vulnerabilities, SOC 2 control failures, accessibility regressions on WCAG-required flows. These bugs carry regulatory or legal consequences beyond the user experience.
• Revenue-path failure: Checkout flow, subscription renewal, billing API, ad-serving pipeline. If the bug stops money from moving, it is critical until proven otherwise.
• Cross-customer regression: A single fix that breaks the same flow for multiple tenants. The blast radius is the deciding factor, not the severity of any one report.
• Time-sensitive event: A release ships in 24 hours, a customer demo is tomorrow, a marketing launch is tied to a feature. Bugs that block a fixed deadline get critical treatment even if their underlying severity is lower.
• Reproducibility: A bug that reproduces every time on a known scenario is easier to prioritize as critical than an intermittent one. Intermittent bugs without a clear pattern usually start at P2 pending root cause analysis.

Document these criteria in the team's testing charter and review them every quarter. Without a written bar, "critical" drifts to mean whatever the loudest stakeholder says it means, and the bug life cycle loses its prioritization signal.

How to Ensure Continuous Improvement in the Bug Life Cycle

A bug life cycle that stays the same year after year is broken. Continuous improvement of the cycle itself is what separates teams that ship faster bug fixes each quarter from teams that wonder why every release feels harder than the last. Three practices drive most of the gains.

• Clear taxonomies: Define bug categories (UI, API, data, performance, accessibility, security) so triage routes faster and metrics aggregate cleanly. A bug tagged as "UI" routes to a different team than a bug tagged as "data," and the report dashboards become useful only when the categories are consistent.
• Root cause analysis on every P1: After close, log the root cause (logic error, missing validation, integration mismatch, flaky dependency, environment drift) and feed the taxonomy. Three months of RCA data reveals the patterns that prevent future bugs, not just the symptoms.
• CI/CD integration: Run the regression suite on every pull request. Cloud test grids can execute 100+ browser and device combinations in parallel, so the bug life cycle starts catching defects before they ever reach the New state. Test Intelligence on TestMu AI separates flaky test runs from genuine defects automatically, so the New queue stays signal-rich.

The other half of continuous improvement is the tooling you run the cycle on. The right tracker enforces the workflow, surfaces aging bugs, and integrates with the test runner so logging a defect takes a single click.

Top Bug-Tracking Tools

A bug tracker is the system of record for the cycle. The right tool depends on team size, framework integration, and how much workflow customization you need. The four below cover the common ground from startups to enterprise.

Whichever tracker you pick, the test runner should push bug context into it automatically. Manual copy-paste of session details is where bug-handling time leaks. The test tool guide goes deeper on tracker selection criteria.

Bug Life Cycle Workflow in Jira

Jira is the most common tracker for the bug life cycle in enterprise teams, but the default Jira workflow uses fewer statuses than the 9-stage canonical model. Most teams customize the Bug issue type with a workflow that maps directly to the stages above. A typical mapping:

Two Jira features make this workflow run cleanly:

• JQL for stuck bugs: A filter like status = "In Review" AND updated < -3d AND priority in (P1, P2) surfaces bugs waiting on QA for more than 3 days, which is the most common stall point.
• Automation rules for SLA: Trigger a Slack notification when a P1 bug sits in any status for more than 24 hours, or auto-escalate to the release manager when a P1 misses the sprint cut-off.

Pair the Jira workflow with cloud test sessions and the bug ticket arrives pre-filled with reproduction video, console logs, network HAR, and device metadata. The bug-tracking integrations docs walk through the one-click setup for Jira specifically.

Defect Life Cycle in Manual Testing

The states are identical whether the bug was found by an automation run or by a tester clicking through the application. What changes in manual testing is the evidence trail: there is no auto-generated session video, no console.log dump, no network HAR file unless the tester captures them deliberately. That puts more weight on the report itself.

A typical manual-testing pass through the cycle looks like this:

• Exploratory or scripted execution: Tester follows a charter or test case, finds a defect, and pauses to capture state (screenshot, screen recording, browser console open).
• Log as New: Report goes into the tracker with reproduction steps, environment (device, OS, browser version, build), expected vs actual, and the captured artifacts attached.
• Triage and Assigned: Triage assigns severity and priority. Without auto-attached logs the developer may need more context, so a manual-testing report should over-document rather than under-document.
• Developer fix: Same as automation, Open then Fixed.
• Retest on the same device: The tester must re-run the original scenario on the same device and OS version where the bug was found. Manual testers rotate through devices, so retest on a different device can falsely pass.
• Verified and Closed: Confirmed fix, closed in the build.

The biggest manual-testing failure mode is the Reopened-Closed-Reopened thrash: a bug is fixed, retested as Verified on an emulator, closed in the build, then a customer hits it on a real device. Running manual exploratory sessions on a real device cloud avoids the emulator-vs-real-device gap and pairs each manual session with capture artifacts automatically, so the manual report carries the same evidence quality as an automation run.

Mobile App Bug Lifecycle

The 9 canonical stages apply to mobile app bugs the same way they apply to web defects, but three things change in the mobile workflow and they all push fix-time up if you ignore them.

• OS and device fragmentation: A bug that does not reproduce on iOS 18 may be P1 on iOS 16 because of a deprecated API path, and iOS version fragmentation only widens as Apple ships new OS releases. Android fragmentation is even wider; the same APK can crash on a 3-year-old Samsung mid-tier and pass on a current Pixel. Mobile bug reports must name the exact OS version, device model, and app build, or the developer cannot reproduce.
• Crash logs are the primary artifact: Where web bugs live in the console, mobile bugs live in the system crash log (iOS .ips, Android logcat). The Retest stage depends on the tester capturing the crash log on the same device class. A screenshot is not enough.
• Store-review rejection bugs: A defect that ships through the cycle and gets caught by Apple App Review or Google Play pre-launch testing has its own SLA, the team has hours, not days, to push a fix. These bugs jump the priority queue automatically and often skip Triage.

Two stages need extra attention for mobile apps:

• Open (root cause): Mobile reproduction failures are usually environment, not code. The developer needs the same device OS and app build the tester used. Without that pairing, bugs bounce to Non-Reproducible.
• Retest: Must run on the same device class. Emulators hide bugs that depend on hardware features (Bluetooth, GPS, camera permissions, battery state). A Verified status from an emulator-only retest is unreliable.

TestMu AI runs Appium, Espresso, and XCUITest suites on 10,000+ real iOS and Android devices in the cloud, automatically capturing crash logs, device logs, video, and network traffic for every session. Bugs logged from these sessions arrive in Jira or your tracker of choice with all the artifacts a mobile developer needs to reproduce on the first attempt, which eliminates most Non-Reproducible bounces.

How to Detect and Fix Bugs using TestMu AI?

TestMu AI helps you perform manual and automation testing of websites and mobile apps on 10,000+ real desktop and mobile devices across every major OS and browser combination. It provides debugging options that not only help with testing but also assist in debugging your software application. Here are some of them:

• LT Debug: TestMu AI's free developer tool that simplifies the debugging process. It can add, remove, and modify request or response headers, block HTTP requests, throttle network speed, switch user agent strings, simulate web page experience, and perform cross-domain AJAX requests on any website.
• TestMu AI lets you detect UI bugs in real-time by giving you access to pre-installed developer tools on real devices and operating systems.
• If you are using test automation, TestMu AI surfaces Command logs, Console logs, Telemetry logs, and more to help identify and debug issues. Our Test Intelligence clusters similar failures so root-cause analysis is faster.
• We also provide one-click integration with bug-tracking tools so you can log bugs directly while testing your software applications.

To try one-click bug logging in automation testing, see the Mark as Bug in Automation Testing doc.

Final Thoughts

A working bug life cycle is the highest-leverage quality investment a team can make. To put it into practice this week:

• Assign owners to every state. Pick three states in your workflow that have no written owner and assign one to a person, not a team.
• Write P1-P3 in the charter. Without a written priority scale, every triager applies a different bar and the queue drifts.
• Make evidence automatic. Wire your tracker so bug reports arrive with video, console logs, and device metadata already attached.

When every state has a name, an owner, and an SLA, bugs stop leaking into production.