Bug Life Cycle in Software Testing: Stages, Workflow & Example

A bug rarely moves directly from “reported” to “fixed.” It must be reviewed, prioritized, assigned, investigated, corrected, retested, and formally closed. It may also be rejected, deferred, marked as a duplicate, or reopened after an unsuccessful fix.

The bug life cycle gives teams a shared process for managing these transitions. At any point, the bug’s status should answer three practical questions:

• What is happening with the defect now?

• Who is responsible for the next action?

• What must happen before its status changes?

This guide explains every common bug status, shows the complete workflow, and demonstrates how it can be implemented in Jira.

What is a bug?

A bug is a difference between the software’s actual and expected behavior.

The expected behavior may be defined by:

• Product requirements;

• Acceptance criteria;

• Technical specifications;

• Designs;

• Contracts between services;

• Regulatory requirements;

• Established behavior in a released product;

• Reasonable user expectations.

For example, if a checkout page charges a customer twice after one click, its actual behavior conflicts with the expected result of creating one payment. That is a bug even if the original requirement did not explicitly say, “Do not create duplicate charges.”

Bugs can originate in requirements, design, source code, configuration, infrastructure, test data, third-party integrations, or deployment. Different failures also require different handling. Our guide to the main types of defects in software testingexplains how functional, performance, security, compatibility, usability, and other defects differ.

What is a bug life cycle?

The bug life cycle is the sequence of statuses and actions through which a software defect moves from discovery to final resolution.

A typical bug follows this path:

New → Triage → Assigned → In Progress → Fixed → Ready for Retest → Verified → Closed

If the fix does not work, the bug moves from retesting to Reopened and returns to development.

Not every bug completes the primary path. During triage or investigation, it may receive an alternative resolution such as:

• Duplicate;

• Rejected;

• Not a Bug;

• Cannot Reproduce;

• Deferred;

• Won’t Fix.

The exact workflow differs between organizations. A small product team might use four statuses, while a regulated enterprise may add code review, security verification, release approval, and audit stages.

Bug life cycle diagram

Bug life cycle stages and statuses

1. New

A bug receives the New status when someone records it in a defect-tracking system.

The reporter should provide enough information for another person to understand and reproduce the issue:

• Clear summary;

• Affected build or version;

• Environment;

• Preconditions;

• Steps to reproduce;

• Expected result;

• Actual result;

• Severity and suggested priority;

• Screenshots, video, logs, or traces;

• Relevant test data.

A new report is not automatically a confirmed defect. It must first be reviewed.

Responsible person: Reporter or QA engineer
Next step: Initial review and triage

2. Triage

During Triage, the team decides whether the report is valid, how serious it is, and when it should be addressed.

A triage group may include a QA engineer, developer, product owner, support representative, engineering lead, or security specialist. The participants depend on the type and potential impact of the problem.

They review:

• Reproducibility;

• Severity;

• Business priority;

• Affected users;

• Release impact;

• Security or compliance exposure;

• Existing duplicate reports;

• Available workarounds;

• Ownership.

Triage should separate severity from priority. A defect can be technically severe but have a lower immediate priority if it affects an unused feature. A visually minor issue can become high priority when it appears on a campaign landing page hours before launch.

Responsible people: QA lead, product owner, engineering lead
Next step: Assign, request information, defer, reject, or close with another resolution

3. Assigned

A confirmed bug becomes Assigned when a developer or responsible team accepts ownership.

Assignment should be based on the affected component rather than simply giving the issue to the person with the smallest workload. Incorrect ownership creates queues, reassignment, and delayed resolution.

The assignee reviews the report and may request:

• Additional logs;

• A database snapshot;

• Exact test data;

• Browser or device details;

• Network traces;

• A production correlation ID;

• Access to the affected environment.

Responsible person: Development lead or assigned developer
Next step: Begin investigation

4. Open or In Progress

Open or In Progress means that the defect is under active investigation or correction.

The developer should determine:

• The root cause;

• The actual blast radius;

• Whether related components are affected;

• Whether the requirement is ambiguous;

• Which tests need to be added or updated;

• Whether a data repair or migration is required;

• Whether the fix creates compatibility or deployment risks.

A bug may leave this stage without being fixed. Investigation can show that it is a duplicate, expected behavior, a configuration issue, or impossible to reproduce with the available evidence.

Responsible person: Developer
Next step: Fix, reassign, request more information, defer, or select another resolution

5. Fixed or Resolved

A bug becomes Fixed after the developer implements the correction and completes the required development checks.

The status should mean more than “the code was changed.” Before moving the issue forward, the developer should normally:

• Review the change;

• Add or update unit and integration tests;

• Confirm that the original scenario now works;

• Check related behavior;

• Link the commit or pull request;

• Identify the build containing the fix;

• Document any configuration or data changes;

• Explain areas that require regression testing.

Some teams use Resolved at this point. Others reserve “Resolved” as a broader category covering Fixed, Duplicate, Won’t Fix, and similar outcomes.

Responsible person: Developer
Next step: Deploy the corrected build to the QA environment

6. Ready for Retest

Ready for Retest indicates that the fix is available in an environment where QA can verify it.

This status is useful when code has been fixed but the build has not yet been deployed. Without it, an issue may appear ready for QA while the tester still cannot access the corrected version.

Before moving the bug into this status, confirm:

• The correct build is deployed;

• Required configuration changes are applied;

• Test data is available;

• Dependencies are working;

• The issue contains implementation notes;

• The original environment can be reproduced where necessary.

Responsible people: Developer, DevOps, or release engineer
Next step: QA retesting

7. Retest

During Retest, the QA engineer reproduces the original scenario against the corrected build.

The tester should verify:

Retesting and regression testing are not identical. Retesting confirms that a specific defect was corrected. Regression testing examines whether the change damaged existing functionality.

Responsible person: QA engineer
Next step: Verify the fix or reopen the bug

8. Reopened

A bug is Reopened when the tester can still reproduce it or when the fix creates an unacceptable result.

The QA engineer should not merely return the issue with the comment “Still broken.” The updated report should include:

• Build and environment;

• New reproduction evidence;

• Actual and expected results;

• Whether the behavior changed;

• Logs, screenshots, or video;

• Any new side effects;

• Test data used.

The issue then returns to the developer for further investigation.

Responsible person: QA engineer, followed by the developer
Next step: Reassign and continue investigation

9. Verified

A bug becomes Verified when QA confirms that the correction works and the relevant regression scope has passed.

This status separates technical verification from administrative closure. It is useful when a fix still needs release approval, documentation, stakeholder confirmation, or deployment to production.

Responsible person: QA engineer
Next step: Close or move to release approval

10. Closed

Closed is the final status for a completed defect.

Before closure, the team should have evidence showing:

• The selected resolution;

• The version containing the fix;

• Retest result;

• Relevant regression result;

• Supporting attachments;

• Any remaining limitations;

• Required stakeholder approval.

A closed defect can still be reopened if the problem returns in a later build or the original resolution proves incorrect.

Responsible person: QA engineer, QA lead, product owner, or designated workflow owner
Next step: None unless the issue recurs

Bug status responsibility table

Alternative bug statuses and resolutions

Duplicate

Use Duplicate when an existing issue describes the same underlying defect.

Link the reports and keep the most complete or oldest appropriate issue as the primary record. Useful evidence from the duplicate – including affected users, environments, and logs—should be copied or linked rather than discarded.

Rejected or Not a Bug

A report can be rejected when the observed behavior matches the approved requirement.

The resolution must include an explanation. If the requirement itself creates a poor user experience, the team may close the defect but create a separate product-improvement request.

Cannot Reproduce

Cannot Reproduce means the team could not trigger the behavior with the available steps and evidence. It does not prove that the bug never occurred.

Before closing, request relevant information such as:

• Exact time of occurrence;

• User or account ID;

• Logs or correlation ID;

• Device, browser, and operating system;

• Network conditions;

• Test data;

• Video or screenshot;

• Frequency;

• Previous actions in the session.

Intermittent defects may require additional logging or production monitoring rather than repeated manual attempts.

Deferred or Postponed

A valid issue becomes Deferred when the team intentionally moves it to a later release.

The decision should identify:

• Reason for postponement;

• Residual risk;

• Available workaround;

• Target release or review date;

• Decision owner.

Avoid using Deferred as a permanent storage area for bugs nobody wants to discuss.

Won’t Fix

Won’t Fix indicates that the problem is valid but the team has deliberately chosen not to correct it.

Possible reasons include low impact, disproportionate implementation risk, imminent feature retirement, third-party limitations, or the availability of a safe workaround. The rationale should remain visible for future review.

Defect life cycle vs bug life cycle

Defect life cycle and bug life cycle are usually used as synonyms. Both describe how an identified software problem moves from reporting to resolution.

Some organizations use the words differently:

• Error: A human mistake in requirements, design, or implementation;

• Defect: A flaw introduced into a work product;

• Bug: An informal term for a defect in software;

• Failure: Incorrect behavior observed while the software is running;

• Incident: An event that requires investigation but is not yet confirmed as a defect.

The distinctions can be useful in formal quality processes, but workflow clarity matters more than terminology. If the team uses “bug” and “defect” interchangeably, document that convention and apply it consistently.

Bug life cycle example in Jira

Consider an eCommerce defect:

Summary: Applying the same promotional code twice reduces the order total twice.

New

A QA engineer creates a Jira bug containing:

• Affected build;

• Test account;

• Preconditions;

• Steps to reproduce;

• Expected single discount;

• Actual double discount;

• Screen recording;

• API response;

• Severity: Major.

Triage

The team confirms that the issue affects checkout totals and could cause direct financial loss. It assigns high priority and gives ownership to the checkout team.

Assigned and In Progress

A developer identifies that the frontend disables the promo button after use, but the API does not prevent the same code from being submitted twice.

The developer adds server-side validation, creates an automated API test, and links the pull request.

Fixed and Ready for Retest

The correction is deployed to the QA environment. The issue includes the build number and notes that promotion stacking and checkout totals require regression coverage.

Retest

QA verifies:

• Repeating the same code does not add another discount;

• A valid different promotion follows the configured stacking rules;

• Removing and reapplying the code works correctly;

• Totals remain correct after cart changes;

• The API rejects duplicate submissions;

• Existing checkout flows still pass.

Verified and Closed

After successful retesting and regression, QA marks the bug Verified. The workflow owner closes it with the resolution Fixed.

If the API continued accepting duplicate submissions, QA would attach new evidence and move it to Reopened.

How the bug life cycle works in Jira

In Jira, a workflow consists of statuses and transitions. Atlassian’s workflow documentation explains that statuses represent the stages of work, while transitions define how a work item can move between them.

A practical Jira defect workflow could contain:

To Do category

• New;

• Triage;

• Assigned;

• Deferred.

In Progress category

• In Progress;

• Code Review;

• Ready for Retest;

• Retest;

• Reopened.

Done category

• Closed;

• Duplicate;

• Rejected;

• Won’t Fix.

Avoid confusing a Jira status with its Resolution field. Atlassian notes that Jira considers an item open when Resolution is empty and closed when it contains a value – even if the visible status name suggests otherwise. Resolutions such as Fixed, Duplicate, Cannot Reproduce, and Won’t Fix should therefore be set only when the defect moves into a final state. The correct configuration is described in Atlassian’s guidance on Jira workflow transitions.

How to design an effective defect workflow

Keep statuses meaningful

Every status should represent a real change in responsibility or process. If two statuses require the same owner and next action, consider combining them.

Define entry and exit criteria

For example, a bug should not enter Ready for Retest until the corrected build is deployed and identified in the issue.

Assign one clear owner

A status such as “Waiting” is ambiguous. Use “Waiting for Reporter,” “Waiting for Deployment,” or “Waiting for Product Decision” so that responsibility remains visible.

Separate status, severity, priority, and resolution

These fields answer different questions:

• Status: Where is the bug now?

• Severity: How much technical or user impact does it have?

• Priority: When should the team address it?

• Resolution: How did the issue end?

Limit unrestricted transitions

Allowing every status to move directly to every other status makes reporting unreliable. Define the transitions that reflect the actual process while retaining an exception path for authorized users.

Automate administrative work

Workflow automation can:

• Assign issues by component;

• Notify the next owner;

• Require fields before transition;

• Set the resolution;

• Add deployment information;

• Reopen linked work after a failed retest;

• Escalate high-severity defects;

• Track time in each status.

Automation should support the process rather than silently make product decisions.

Review workflow metrics

Useful defect-flow metrics include:

• Time from New to Triage;

• Time from Assigned to Fixed;

• Time waiting for deployment;

• Retest waiting time;

• Reopen rate;

• Percentage of duplicates;

• Age of deferred defects;

• Defects by resolution;

• Escaped defects;

• Time spent in blocked statuses.

Long waiting time often reveals a process constraint more clearly than the total number of bugs.

A useful bug life cycle makes the next action obvious

The purpose of a defect workflow is not to create more status fields. It is to prevent bugs from becoming ownerless, unverified, or incorrectly closed.

A useful bug life cycle makes three things visible at every stage: the current state of the defect, the person responsible, and the evidence required for the next transition. When those rules are clear, teams spend less time asking where a bug is and more time resolving it correctly.

Ready to rethink your QA?

Schedule a call

Frequently asked questions

What is the first stage of the bug life cycle?

The first stage is usually New, when the defect is recorded in a tracking system. Some teams begin with Draft or Reported before the issue becomes visible for triage.

What is the final stage?

The standard final stage is Closed. However, the resolution may be Fixed, Duplicate, Rejected, Cannot Reproduce, or Won’t Fix.

Who closes a bug?

QA commonly closes a fixed defect after successful retesting. A product owner, QA lead, or workflow manager may close rejected, deferred, duplicate, or business-related resolutions. The team should document this responsibility.

What is the difference between Fixed and Closed?

Fixed means a developer has implemented a correction. Closed means the team has completed the required verification and administrative steps.

When should a bug be reopened?

Reopen a bug when the original problem remains, the fix works only partially, the correction introduces an unacceptable side effect, or the previous resolution is proven incorrect.

Can a closed bug be reopened?

Yes. A closed bug can be reopened if it appears again or new evidence shows that it was not resolved correctly. Some teams create a new linked defect when the recurrence occurs in a substantially different version.

Is every bug required to pass through all statuses?

No. A duplicate may move from Triage directly to Closed. A valid issue may be Deferred. A critical production defect may use an emergency workflow with fewer approval stages.

How many statuses should a defect workflow have?

Use the smallest number that makes ownership, progress, and reporting clear. A small team may need five or six statuses. A regulated or multi-team product may require additional review, deployment, and approval stages.

About the author

Anastasiia Sokolinska

Chief Operating Officer

Anastasiia Sokolinska is the Chief Operating Officer at DeviQA, responsible for operational strategy, delivery performance, and scaling QA services for complex software products.