Bug Life Cycle in Software Testing

A bug life cycle, also known as a defect life cycle, refers to the various stages that a bug or defect goes through during the software testing process. This life cycle of a bug tracks its journey from discovery to resolution, detailing each phase to ensure that no issue goes unresolved. Each stage involves a specific state that represents the current status or progress of the bug.

🎯 TL;DR - Defect Life Cycle

• A bug life cycle tracks the stages a defect goes through, from discovery to resolution, ensuring all issues are properly addressed and fixed.
• Key stages include "New," "Assigned," "Open," "Fixed," "Pending Retest," "Retest," "Verified," and "Closed," with possible alternate statuses like "Deferred" or "Rejected."
• Bug triage prioritizes defects based on severity, while bug tracking tools like Jira streamline progress monitoring.
• Automation enhances efficiency in bug management by expediting verification and reducing human error during the life cycle stages.

What is a Bug Life Cycle?

When a bug occurs, it is initially posted by the tester in a bug tracking tool like Jira, where details such as the issue description, steps to reproduce, environment details, and the "expected behavior" (if known to the person reporting the bug or linked to a specific requirement) are logged.

The bug is then assigned to the developer, who is responsible for investigating and fixing it. During this time, the development team members work closely with testers to resolve the defect. As the defect moves through different states throughout its lifecycle, it may be marked as "not a bug" if it is determined that the issue is not an actual defect but a misunderstanding of the requirements.

However, if it is a valid bug, the goal is to get it fixed.

Stages of the Defect Life Cycle

The exact names can vary, but this is a practical software defect workflow.

These aren't universal Jira statuses. They're common states teams use to express the underlying process.

Let’s explore the different stages of the bug life cycle in testing:

1. New

When a tester discovers a defect during the testing phase, they log it into a bug tracking system like Jira. At this point, the defect is in the "New" state, awaiting review. Essential information such as environment details, the test case that failed, and steps to reproduce the defect are included in the bug report.

2. Assigned

Once the defect is posted, it gets assigned to the development team. The project manager or lead developer reviews the bug and assigns it to a team member for resolution. The status is changed from "New" to "Assigned."

3. Open

The developer starts working on the defect, changing the status to "Open." At this stage, the developer will investigate the bug and determine the necessary code changes to fix it.

4. Fixed

When the developer fixes the bug, the status is updated to "Fixed." The necessary changes are made, and the bug is ready for further testing. It does not mean QA has confirmed the correction. That's why Fixed and Closed shouldn't be treated as synonyms.

5. Pending Retest

After the bug is marked "Fixed," it is sent back to the tester for testing. The tester checks whether the defect was truly fixed by executing the relevant test cases again. The bug is now in the "Pending Retest" stage.

6. Retest

In this stage, the tester re-tests the bug using manual or test automation techniques to verify if the bug is resolved. If the test case passes, the bug can move to the next stage. The team may also run relevant regression testing around adjacent behavior because a fix can introduce new problems elsewhere.

7. Verified

If the bug is fixed and the test case no longer fails, the tester changes the status to "Verified." This confirms that the issue is no longer present in the software.

8. Closed

Once the bug is "Verified," it is marked as "Closed," signifying that the bug is resolved. Closure means the team considers the issue resolved and no further work is expected under that defect record.

Other Possible States of a Bug

While the main stages define the general flow, there are other statuses that a bug can assume during its life cycle:

• Reopened: If the bug persists even after the developer fixes it, the tester can mark it as "Reopened," sending it back to the developer for further action.
• Deferred: In some cases, a bug may not be critical for the current release and is deferred to be fixed in the next release.
• Rejected or Not a Bug: If the development team determines that the reported issue is not a bug (e.g., it may be due to a misunderstanding of requirements), the status is marked as "Rejected" or "Not a Bug."
• Duplicate: A duplicate defect describes an issue already tracked elsewhere. The duplicate report should link to the canonical defect before closure.
• Non-Reproducible: The team cannot recreate the reported failure. Don't rush to close it. Before doing that, compare browser and version, operating system, application build, user permissions, test data, network conditions, logs and feature flags. Intermittent defects often disappear when one of these variables isn't captured.
• Need More Information: The team can't investigate responsibly with the available report. Instead of closing the issue, ask for the missing information, such as exact reproduction steps, environment, account type, a screenshot or video, a console error, a timestamp, a request ID or the expected result. A well-written report shortens this state considerably.

Bug Triage

Bug triage is the process of reviewing and prioritizing bugs. During triage, bugs are assigned a priority level based on their severity and impact on the software product. The testing team and project managers often decide whether to resolve the bug immediately or defer it for a future release.

Bug Status vs Severity vs Priority

These terms describe three different things.

Status tells you where the defect currently is in its workflow.

Severity describes how badly the defect affects the software.

Priority describes how urgently the team wants it fixed.

Four Practical Severity Levels

Four Practical Priority Levels

Severity and priority often correlate, but not always.

Consider a cosmetic typo in the primary homepage headline two hours before a major product launch. Its technical severity is low. Nothing stops working. Its business priority may still be P0 because millions of visitors are about to see it.

The reverse can happen too. A technically severe failure in an obsolete internal feature used once per year may receive lower product priority than a widespread moderate defect affecting checkout conversion.

Separating the two fields makes triage clearer.

The Role of Bug Tracking Tools

Tools like Jira, Bugzilla, and others play a vital role in the bug life cycle. These bug tracking systems help testers and developers stay updated on the status of bugs, track progress, and ensure no defects fall through the cracks. By using these tools, teams can easily check the current state or progress of any bug in the system.

Bug Life Cycle in Jira

A Jira bug life cycle is implemented as a workflow made of statuses and transitions rather than one mandatory Jira-specific sequence.

Atlassian defines a workflow as the path a work item follows from creation to completion. Statuses describe where the item currently sits, while transitions define which moves are possible between statuses.

A simple Jira bug workflow could be:

To Do → In Progress → Ready for QA → QA → Done

A more explicit defect workflow could use:

New → Assigned → Open → Fixed → Retest → Closed

with transitions back to Reopened when verification fails.

Jira also distinguishes status from resolution.

A ticket can sit in a Done-category status, but its Resolution field is what records why the work is considered complete. Typical defect resolutions might include:

• Fixed
• Duplicate
• Won't Fix
• Cannot Reproduce
• Not a Bug

This distinction matters because Jira reporting relies on Resolution for several completed-item calculations.

Atlassian also notes that transitions are directional. If a bug can move from Retest → Reopened and then later return to Retest, both paths need to exist in the workflow.

Official reference: Atlassian: What are Jira workflows?

The Importance of Automation in Bug Tracking

Automation plays a crucial role in enhancing the efficiency of the bug tracking process, particularly when managing multiple defects or bugs throughout the life cycle stages. When a bug is identified and the defect is assigned to a developer, the software tester can rely on automated tools to ensure swift verification. Automation doesn't manage the bug life cycle for you. It can reduce the time between Fixed and useful verification.

Suppose a bug affected the login flow. After the developer deploys the fix to staging, an automated regression suite can immediately rerun:

• valid login
• invalid password
• password reset
• remembered session
• logout

This can expose a regression before a tester begins a full manual pass.

Recorder-based tools are particularly useful when the person who discovers the bug can turn the same reproduction path into an automated test. BugBug's Record and Play Automation Tools guide explains that model in more detail.

Automation shouldn't automatically update a Jira issue to Verified merely because one script passed unless the team's workflow explicitly treats that result as sufficient evidence. Human ownership still matters.

What Goes Into a Good Bug Report?

The life cycle slows down quickly when developers can't reproduce a defect.

ISTQB's Foundation Level syllabus includes information such as the test object and environment, reproduction details, expected and actual results, severity, priority, status and supporting evidence among typical defect-report data.

A useful practical report contains at least these 8 fields:

1. Clear title. Bad: "Checkout broken". Better: "Checkout: Place Order returns 500 error for logged-in EU customers using PayPal". The better version identifies feature, symptom and conditions before anyone opens the issue.
2. Environment. Include the environment, application version/build and browser/device where relevant.
3. Preconditions. Explain the state required before reproduction, for example: "User has an active account and one physical product in cart."
4. Steps to reproduce. Use numbered steps. Keep each step specific enough that another person can follow it without interpretation.
5. Expected result. Describe what should happen.
6. Actual result. Describe what happens instead.
7. Severity and priority. Record the impact and urgency separately.
8. Evidence. Add useful evidence such as a screenshot, video, console output, network request, logs, test case or timestamp.

For reusable testing documentation, see BugBug's Test Case Template.

How to Write Bugs That Move Through the Life Cycle Faster

A fast defect workflow starts before the issue becomes Assigned.

• Reproduce before filing when possible. One reliable reproduction is more useful than a vague report based on memory.
• Include the smallest useful evidence. Don't attach 15 screenshots when one 20-second recording shows the failure.
• Separate observations from assumptions. Write "Network request /checkout returned HTTP 500" rather than "Backend database is broken" unless you've actually established the root cause.
• Link the failed test. When a known test case failed, attach it. That gives the developer exact preconditions and expected behavior.
• Keep one defect per independently fixable problem. A bug titled "Checkout, login and profile have issues" creates unclear ownership and closure criteria. Split independent problems unless one root cause clearly connects them.

For a broader pre-release checklist, see BugBug's QA Checklist for Website Testing.

Example of a Bug Life Cycle

Let’s take an example of a bug found in an e-commerce website:

1. New Defect: The tester finds that the checkout button on the website is not working.
2. Assigned to Developer: The bug is logged in Jira and assigned to a developer.
3. Developer to Fix: The developer investigates the issue, makes the necessary changes, and marks the bug as "Fixed."
4. Tester Re-Tests the Bug: The tester checks the functionality of the checkout button.
5. Bug Verified and Closed: If the button works correctly, the bug is marked as "Verified" and then "Closed."

Example: A Checkout Bug From Report to Closed

Consider an ecommerce site where removing an item from the cart occasionally leaves the old total visible at checkout.

1. New. QA reports "ECOM-418: Checkout total isn't recalculated after cart item removal". Severity: High. Priority: P1.
2. Assigned. The QA lead confirms the issue and assigns it to the checkout team.
3. Open. A developer reproduces the issue. The cart API returns the correct total, but the frontend retains a stale cached value.
4. Fixed. The developer updates the state invalidation logic and adds a component test.
5. Pending Retest. The new build reaches staging. Jira status: Ready for QA.
6. Retest. QA adds Product A (€60) and Product B (€40), sees €100 in the cart, removes Product B and continues to checkout, expecting €60. The checkout still displays €100 after navigating with the browser Back button. Jira status: Reopened.
7. Back to Open. Development discovers a second stale-state path triggered by browser history restoration.
8. Fixed again. The second code path is corrected. A regression test is added for both normal navigation and browser-history navigation.
9. Retest and Verified. QA reruns both paths. Cart and checkout totals now remain synchronized.
10. Closed. QA closes the defect and keeps the regression scenario in the release suite.

This example shows why the defect life cycle needs a loop. The first fix can fail verification without the workflow itself failing.

Final Thoughts on Bug Life Cycle

The software testing bug life cycle is an essential part of the software development process. Each stage of the cycle ensures that bugs are systematically tracked, resolved, and verified, leading to a high-quality software product. Whether the defect is fixed by the developer, deferred, or rejected, following a structured workflow helps ensure efficient software quality and smooth project management.

The entire bug life cycle is a collaborative effort between the testing team, development team, and project managers, all working to resolve and deliver a reliable and functional software product.

Frequently Asked Questions About the Bug Life Cycle

What is the bug life cycle in software testing?

The bug life cycle is the sequence of statuses a software defect follows from initial reporting through investigation, fixing, retesting and closure. A typical path is New → Assigned → Open → Fixed → Retest → Verified → Closed, with branches such as Reopened, Deferred or Rejected.

What is the bug life cycle in Jira?

Jira doesn't require one specific bug life cycle. Teams configure workflows using statuses and transitions. A common Jira defect workflow might use New → In Progress → Ready for QA → QA → Done, with a transition back to Reopened when verification fails.

Are bug life cycle and defect life cycle the same?

Usually, yes. QA teams commonly use the terms interchangeably. Some standards and organizations prefer “defect” or “anomaly” because those terms cover a wider range of software discrepancies than coding bugs alone. If you're unsure about the terminology itself, start with Bug vs Defect: What's the Difference?.

What does Deferred mean in a bug life cycle?

Deferred means the team has confirmed the defect but intentionally postponed the fix. This can happen when impact is low, a release is approaching, the affected feature will soon change or the fix costs more than the current business risk justifies.

What happens when a fixed bug fails retesting?

QA reopens the defect and returns it to development. The team investigates why the proposed fix didn't resolve the complete issue, implements another correction and repeats the retest cycle before verification and closure.

What is defect leakage?

Defect leakage measures defects that escape the testing stage where the team expected to find them and are discovered later, often in production. A commonly used formula divides escaped defects by total relevant defects and expresses the result as a percentage.

Happy (automated) testing!