The bug life cycle is the sequence of statuses a reported defect passes through between reporting and closure: open, in progress, fixed, retested, closed or reopened. The ISTQB Foundation Level syllabus 4.0.1 lists eight example statuses, from “open” to “rejected” (ISTQB CTFL 4.0.1, 2024). Jira, Azure DevOps and Bugzilla model the same flow with their own names. The status is a field in the defect report and shows who has to act next. A fixed defect is closed only after the confirmation test passes, and a later regression gets a report of its own.

TL;DR: The bug life cycle moves a defect report from “open” through “waiting to be fixed” and “awaiting confirmation testing” to “closed”, with side exits for duplicate, deferred and rejected reports. Close a fixed bug only after a passed confirmation test. If the bug returns later as a regression, Microsoft recommends a new, linked bug.

Figure 1: The bug life cycle with the ISTQB example statuses

What is the bug life cycle?

The bug life cycle (or defect life cycle) is a defined workflow that moves every reported defect through set statuses until it is closed. The official ISTQB glossary defines defect management as “the process of recognizing, recording, classifying, investigating, fixing and disposing of defects” (ISTQB Glossary). The life cycle is the status track inside that process.

The status is a field in the defect report. It shows at a glance where a report stands and who has to act next. ISTQB defines a defect report as “documentation of the occurrence, nature, and status of a defect” (ISTQB Glossary). The full process is covered in our guide to defect management in software testing.

Not every report describes a real defect. The syllabus says reported anomalies “may turn out to be real defects or something else (e.g., false-positive result, change request)” (ISTQB CTFL 4.0.1, 2024). Statuses such as “rejected” exist for exactly these cases. Example, as an illustration: a tester reports a wrong interest display, the business team classifies it as intended behavior, and the report ends as “rejected”.

Which defect statuses does ISTQB list?

The ISTQB syllabus lists eight example defect statuses: open, deferred, duplicate, waiting to be fixed, awaiting confirmation testing, re-opened, closed and rejected (ISTQB CTFL 4.0.1, 2024). The list follows an “e.g.”; it gives examples and does not prescribe a workflow.

Here is how to read the eight statuses:

• Open: reported, not yet assessed or assigned.

• Waiting to be fixed: confirmed as a defect, development is up next.

• Awaiting confirmation testing: development reports a fix, the retest is pending.

• Closed: retest passed, the defect report is complete.

• Re-opened: the retest failed, the failure still occurs.

• Deferred: a real defect the team chose to fix later.

• Duplicate: the same defect has already been reported.

• Rejected: not a defect, for example a false-positive result.

Three of these statuses end the cycle without a fix: duplicate, rejected and often deferred. Jira and Azure DevOps record them as a resolution (close reason) next to a “closed” status. If your team mixes ISTQB terms and tool terms, settle this point once.

How does the bug life cycle work, step by step?

A typical bug life cycle has six steps: report, assess, fix, mark as resolved, retest, and close or reopen. Each step has a clear owner. The ISTQB syllabus names the core activities: log the reported anomalies, analyze and classify them, decide on a response and close the defect report (ISTQB CTFL 4.0.1, 2024).

1. Report (tester, business user or customer): The defect report is created. Per ISTQB, the tool may fill in the identifier, date, author and initial status automatically. Status: open.

2. Assess (triage): The team checks whether it is a real defect, sets severity and priority and decides: fix, defer, or close as duplicate or rejected. Microsoft notes that “typically, the project owner runs the bug triage meetings” (Microsoft Learn, 2026).

3. Fix (development): A developer picks up the defect. Status: waiting to be fixed, then in progress.

4. Mark as resolved (development): The fix is delivered. Status: awaiting confirmation testing (“Resolved” in Jira and in Azure DevOps Agile and CMMI).

5. Retest (tester or reporter): In the Azure DevOps Agile and CMMI processes, the person who created the bug verifies the fix and closes it (Microsoft Learn, 2026).

6. Close or reopen (test team): Passed means closed. Failed means re-opened, and the defect goes back to step 3.

The syllabus states: “The process must be followed by all involved stakeholders.” (ISTQB CTFL 4.0.1, 2024). In practice, configure which role may trigger which transition. We recommend one simple rule: nobody closes their own fix.

What are the bug states in Jira, Azure DevOps and Bugzilla?

Jira, Azure DevOps and Bugzilla model the same bug life cycle with their own status names, and all three separate the status (where is the bug?) from the resolution (why was it closed?). Bugzilla describes the purpose of the pair as covering everything “from not even being confirmed as a bug, through to being fixed and the fix confirmed by Quality Assurance” (Bugzilla documentation).

Figure 2: Same phases, different state names in Jira, Azure DevOps and Bugzilla

In the Azure DevOps column, the value before the dot is for the Agile and CMMI processes (written as Agile / CMMI where the names differ), and the value after the dot is for Scrum. The Azure DevOps Basic process has no Bug type at all.

Sources: Atlassian, Microsoft Learn (2026), Bugzilla. The Bugzilla names follow the default workflow since version 4.0; the official documentation shows it only as a diagram, and every installation can change it. Jira and Azure DevOps are configurable too. Jira statuses depend on the template, and the simplified templates use To Do and Done.

Close reasons differ more than the statuses do:

One detail with consequences: “deferred” is a status in the ISTQB example, yet in Azure DevOps Agile and CMMI “Deferred” is the close reason of a closed bug. A deferred bug there drops out of every query for open bugs. Decide whether postponed defects should stay open in your setup.

Confirmation testing or regression testing: what happens after a fix?

Two different tests follow a fix: confirmation testing checks the fixed defect itself, and regression testing checks what the change did to the rest of the system. ISTQB defines it plainly: “Confirmation testing confirms that an original defect has been successfully fixed.” (ISTQB CTFL 4.0.1, 2024).

Figure 3: Confirmation and regression testing check different things after a fix

For the second test, ISTQB writes: “Regression testing confirms that no adverse consequences have been caused by a change, including a fix that has already been confirmation tested.” (ISTQB CTFL 4.0.1, 2024). The confirmation test decides between “closed” and “re-opened”. The regression test checks the remaining functions.

The syllabus names two ways to run a confirmation test: rerun all tests that failed as a result of the defect, or add new tests that cover the changes made for the fix. When time is short, it can be restricted to “simply exercising the test steps that should reproduce the failure caused by the defect and checking that the failure does not occur” (ISTQB CTFL 4.0.1, 2024).

Microsoft gives a clear rule for bugs that come back after closure: “Don't reopen closed bugs for regressions. Instead, open a new bug and link it to the original with a Related link.” (Microsoft Learn, 2026). Reopening fits a failed confirmation test. A later regression is a new defect with its own cause and deserves its own report.

How often do bugs get reopened?

In the open-source studies cited here, about 6 to 10% of bugs were reopened in four Eclipse projects (Mi and Keung, 2016) and about 6% across 589 Jira projects (Tagra et al., 2022); there is no universal industry rate. The numbers depend heavily on the dataset. Read them as a reference point for measuring your own rate.

Figure 4: Reopen rates from two open-source studies

Non-reproducible reports are a bottleneck of their own. Joorabchi, Mirzaaghaei and Mesbah found they make up 17% of all bug reports studied and remain active around three months longer (MSR 2014). Mozilla calls steps to reproduce “the most important part of any bug report” (Mozilla Bug Writing Guidelines, 2026). Good steps lower the risk that a report ends up as non-reproducible.

A high reopen rate in your own project can point to weak confirmation tests or unclear acceptance criteria; check the affected reports one by one. Measure it separately from new regressions, or the metric mixes two problems. Our article on test reporting covers where such numbers belong in a test report.

When is a defect done?

A defect is done when the confirmation test has passed, the regression tests are green, and the report is closed with a status and a resolution. Put these criteria into your team's Definition of Done so nobody confuses “resolved” with “done”.

A practical checklist:

• The fix is in the target build, and the version is recorded in the defect report.

• The confirmation test passed in the right test environment.

• A regression test now covers the failure.

• Status “closed” and a fitting resolution are set.

• The report references the test case, the test run and the code change.

Where does Autemos help in the bug life cycle, and where not?

Autemos is AI-assisted software for functional test automation across web, mobile, API and desktop. In the bug life cycle, it mainly supports the confirmation and regression tests. Autemos is not a defect tracker. Jira, Azure DevOps or Bugzilla remain the system where defect statuses are set.

Where Autemos helps:

• Confirmation test by rerun: If an automated Autemos test found the defect, its visual test workflow is the exact step sequence that failed. You run it again after the fix. The exported Playwright or Appium code runs outside Autemos too.

• Turning the fix into a regression test: The AI Recorder drafts an executable test workflow from the Jira ticket via AI chat. The team must approve every AI-generated step before it runs.

• Jira/Xray sync: Test cases and test executions sync both ways with Jira/Xray, so the retest result is visible there.

• Self-healing with a record: Every locator heal is logged in the report and can be rolled back. A changed locator shows up as a test-side change and is not mistaken for a product defect.

Where Autemos does not help: it does not create bug tickets automatically, does not set defect statuses, does not decide severity or priority and does not replace root cause analysis. A person decides between “closed” and “re-opened”. You keep maintaining status, severity and resolution in Jira, Azure DevOps or Bugzilla.

Frequently asked questions

What is the difference between a bug status and a resolution?

The status shows where a bug stands in the workflow, and the resolution explains why it was closed. Bugzilla separates statuses such as RESOLVED from resolutions such as FIXED or DUPLICATE. Jira's default resolutions are Done, Won't do, Duplicate and Cannot reproduce (Atlassian).

Who should close a bug?

Usually the reporter or the test team closes a bug after a passed confirmation test. In Azure DevOps Agile and CMMI, Microsoft says the person who created the bug verifies the fix and closes it (Microsoft Learn, 2026). The developer who built the fix should not close it.

When do you reopen a bug, and when do you file a new one?

Reopen a bug when its confirmation test fails. If the same failure returns as a regression after closure, Microsoft recommends a new bug with a “Related” link to the original (Microsoft Learn, 2026). That keeps the history and the reopen rate meaningful.

What does the “deferred” status mean?

“Deferred” means the team has confirmed a defect and chosen to fix it later, for example in an upcoming release. The ISTQB syllabus lists it as an example status. In Azure DevOps Agile and CMMI, “Deferred” is a close reason, so the bug counts as closed there.

Is there a standard bug life cycle?

There is no binding standard: the ISTQB syllabus presents its eight defect statuses explicitly as examples (“e.g.”). Jira, Azure DevOps and Bugzilla ship their own default workflows, and all can be changed. In Bugzilla, administrators define the allowed transitions in a grid (Bugzilla).

Conclusion

The bug life cycle shows where every reported defect stands and who acts next. The eight ISTQB examples from “open” to “rejected” cover the common cases; Jira, Azure DevOps and Bugzilla name them differently and move some cases from the status into the resolution. Three rules apply. Close a fixed defect only after a passed confirmation test. Reopen only when that confirmation test fails. Give a later regression a new, linked bug. Teams that turn every fixed defect into a regression test will usually catch a returning bug in the next test run. If you want to see how Autemos can handle confirmation and regression tests from Jira tickets in your team, talk to us.