Defect Lifecycle

Error, defect, failure: getting the terms right

The ISTQB glossary and Foundation syllabus describe a causal chain. A person makes an error (also called a mistake): misreads a requirement, forgets a boundary, types the wrong operator. The error produces a defect (also called a fault or a bug) in a work product — a requirement, a design, the code, a test script or a configuration. When the defective part is executed under the right conditions it may cause a failure: the system does not do what it should, and someone or something observes it. Not every defect causes a failure — a defect in code that never runs stays latent — and the syllabus notes that failures can also be caused by environmental conditions.

Two more words cause confusion. Anomaly is the neutral term: an observed deviation from expectation, before anyone has decided whether it is a defect, a misunderstanding, a test error or a change request. IEEE 1044, the Standard Classification for Software Anomalies (listed by IEEE as inactive-reserved), uses anomaly as its umbrella term and defines attributes for classifying anomalies. Incident is overloaded: ISO/IEC/IEEE 29119-3 calls a defect report an incident report (the ISTQB Foundation syllabus points this out), while in operations an incident is an unplanned interruption or degradation of a live service, whatever its cause.

• Error (mistake) — a human action that produces an incorrect result.
• Defect (fault, bug) — an imperfection in a work product; it can be found by a review without running anything.
• Failure — an observed deviation of the running system from its expected behaviour.
• Root cause — the underlying reason the error was made or the defect was not prevented; the target of root cause analysis.
• Anomaly — any observed deviation from expectation, not yet classified.

Where defects are found: reviews, testing and production

Defects enter at every stage of the software development lifecycle and are found at different points in it. A requirement that contradicts another is a defect found by review before any code exists. A wrong calculation is found by a unit, API or system test during the software testing life cycle. A defect that slips through every check is found in production, usually as a failure reported by a user or raised by monitoring. The SDLC and STLC guide and the software testing life cycle guide describe those stages; this page describes what happens to a defect once it is found.

The lifecycle has the same shape in all three cases, but the entry point and cost differ. A defect enters the process through a report; how to write one a developer can act on, and how severity differs from priority, is the subject of the bug report guide. Triage then turns the report into a decision, which the defect triage guide covers in depth. Recording where each defect was found — review, test level or production — is what later lets you measure how many defects escaped each stage.

• Review findings — recorded in the review log or as review comments; closed when the author has corrected the work product and the reviewer has checked the correction.
• Test-phase defects — full lifecycle in the tracker, with confirmation testing and regression testing before closure.
• Production defects — linked to the operational incident, triaged immediately when a live service is affected, and verified in production after the fix is deployed.

The lifecycle states as a diagram

Tracker workflows differ, but almost all of them implement the same underlying states. The diagram uses generic names; a later section maps them to real tools. Solid arrows trace the main path from New to Closed; dashed arrows are the branches: they end a defect without a code change, park it for later, or send it back when a fix does not hold.

• New — recorded, not yet reviewed. Some trackers call it Unconfirmed, Submitted or Untriaged.
• Needs info — waiting for a specific fact from the reporter; the age clock keeps running.
• Open / Assigned — accepted as valid, with severity, priority, an owner and a target release.
• In Progress — the owner is actively investigating or fixing it.
• Resolved — the owner considers the work done, either fixed or with another resolution.
• Reopened — the resolution did not hold; the defect returns to its owner.
• Verified — a tester has confirmed the fix in the stated build.
• Closed — no further work; the record stays for history and metrics.
• Deferred — valid, but consciously postponed to a later release; it still counts as a known open defect.

  failure observed, or defect found in a review
                 |
                 v
             [ New ] ----- facts missing -----> [ Needs info ]
                 |  <------ facts supplied ------------+
                 |
                 +------- triage: no fix needed ------> [ Resolved ]  duplicate | rejected (not a bug)
                 |                                           |         cannot reproduce | won't fix | by design
                 | triage: accepted                          |
                 v                                           | reporter / QA agrees (if not: back to triage)
        [ Open / Assigned ] <----- re-planned -----+         |
             |        |                            |         |
             |        +------ postpone ----> [ Deferred ]    |
             | developer starts                              |
             v                                               |
        [ In Progress ]                                      |
             +-- cannot reproduce --> back to [ Needs info ] |
             | fix merged, build number stated               |
             v                                               |
     [ Resolved: fixed ] -- retest fails --> [ Reopened ] --> back to [ Open / Assigned ]
             |                                               |
             | confirmation test passes, regression green    |
             v                                               v
        [ Verified ] ------- fix shipped ------------> [ Closed ]
                                                             |
                                same failure seen again -----+--> [ Reopened ]

Transitions: who moves a defect and what must be true

A state is only useful if everyone knows who may move a defect out of it and what must be true first. Put these rules into the tracker workflow where it supports conditions and required fields, and into the team's working agreement where it does not.

• New → Open / Assigned — triage group (test lead, product owner, development lead) — reproduced or credibly evidenced, not a duplicate, severity and priority set, a named owner and a target release.
• New → Needs info — triage or developer — the exact missing item is written down (build number, account, request id), not just "more info please".
• Needs info → New — the reporter, or whoever was asked — the requested fact is added to the report; the defect goes back to triage rather than straight to a developer.
• New → Resolved as duplicate, rejected, cannot reproduce, won't fix or by design — triage group — reason recorded, duplicates linked to the original, reporter notified.
• Open → Deferred — product owner — a written reason and a target release or review date; the risk is accepted by someone with the authority to accept it.
• Deferred → Open / Assigned — product owner — the review date or target release has arrived and the defect is re-planned with an owner and a release; a deferral that is extended gets a new written reason.
• Open → In Progress — assigned developer — work has started; a developer who cannot reproduce returns it to Needs info instead of leaving it idle.
• In Progress → Resolved: fixed — developer — the fix is merged, the build that contains it is stated, and a test that covers the failure is added where feasible.
• Resolved: fixed → Verified — tester, preferably the reporter — the confirmation test passes in the stated build with the original steps and data, and the agreed regression checks around the change are green.
• Resolved: fixed → Reopened — tester — the original failure still occurs in the stated build; evidence attached. A different failure found during retest is a new defect.
• Reopened → Open / Assigned — test lead or triage group — the defect goes back to the owner of the fix with the retest evidence attached, and from there to In Progress as before.
• Verified → Closed — tester or release manager — the fix has shipped in the target release, or the team closes on verification if that is the agreed rule.
• Closed → Reopened — anyone, through triage — the same failure is seen again in a build that contains the fix. A different symptom gets a new, linked defect.
• Resolved (not fixed) → Closed — reporter or QA — accepts the resolution; if they disagree, the defect goes back to triage rather than into a comment argument.

Endings other than fixed

Many defect records end without a code change. The ISTQB Foundation syllabus notes that a reported anomaly may turn out not to be a defect at all — a false positive or a change request, for example. Every non-fix ending needs a reason that a reader can check months later.

• Duplicate — the same underlying defect is already recorded. Link to the original, move any better evidence across, and resolve the newer record. The same symptom does not always mean the same cause; if unsure, keep both linked until the fix proves it.
• Rejected / invalid / not a bug — the behaviour matches the requirement, or the report came from a test error such as wrong data or the wrong environment. Quote the requirement. If the requirement itself is wrong, that is a requirements defect or a change request, not a rejection.
• Cannot reproduce / works for me — nobody can make the failure happen again with the information available. Record what was tried (builds, devices, data) and keep the logs and request ids: intermittent defects often return, and the first report is the evidence.
• Won't fix — a real defect the team has decided not to fix, typically because the cost exceeds the impact or the feature is being retired. It is a business decision owned by the product owner and recorded with its reason.
• Deferred — a real defect postponed to a later release. Unlike won't fix it stays open and belongs in the known-issues list that ships with the release notes.
• By design / as designed — the behaviour is intended. When the design surprises users, consider whether that surprise is itself a usability defect worth its own record.

How trackers name it: Bugzilla, Jira and issue trackers

Bugzilla's documentation describes its bug workflow as customisable and shows a default one. In the default, the statuses are UNCONFIRMED, CONFIRMED, IN_PROGRESS, RESOLVED and VERIFIED, and a resolved bug carries one of the resolutions FIXED, INVALID, WONTFIX, DUPLICATE or WORKSFORME. Bugzilla's field help describes VERIFIED as the point where QA has looked at the bug and its resolution and agrees with it, and as the final status. Worth copying: the resolution is a separate field from the status, and "cannot reproduce" is a formal ending, not a comment.

Jira takes the configurable route: each workflow defines its own statuses and transitions, and administrators choose which resolutions are available, so two projects in one company can use different names and paths for the same lifecycle. Lightweight issue trackers keep little more than open and closed, and teams express the rest with labels (needs-info, duplicate, wontfix) and linked pull or merge requests. Whatever the tool, keep a one-page mapping from your tracker's names to the generic lifecycle so that metrics mean the same thing across projects.

Generic state      Bugzilla default               Example Jira project (configured)
-----------------  -----------------------------  ---------------------------------
New                UNCONFIRMED                    Open + label "untriaged"
Open / Assigned    CONFIRMED + assignee           To Do + assignee
In Progress        IN_PROGRESS                    In Progress
Resolved: fixed    RESOLVED / FIXED               Ready for QA, resolution Fixed
Resolved: other    RESOLVED / INVALID, WONTFIX,   Done, resolution Duplicate,
                   DUPLICATE, WORKSFORME          Won't Do, Cannot Reproduce
Verified           VERIFIED (final status)        Verified
Closed             (no separate state)            Closed

Confirmation testing, regression testing and reopening

Two different tests follow a fix, and the ISTQB syllabus names them separately. Confirmation testing, often called retesting, re-runs the steps that failed, in the build that contains the fix, to confirm the defect is gone. Regression testing checks that the change has not broken anything else: the neighbouring features, the other callers of the changed code, the other platforms and locales. A defect is verified when the first passes; a release is safe only when the second does too.

Confirmation testing should start with the original data and environment, then vary one thing at a time — another browser, another role, the neighbouring boundary — because a fix often covers only the exact reported case. Regression scope comes from the change: which modules the diff touched and what depends on them. The smoke, sanity and regression testing guide covers how to size those suites.

• Retest in the build named in the resolution, never in "latest". If that build is not deployed, the defect is not ready for retest.
• Reopen only for the same failure. A new symptom gets a new defect linked to the first; otherwise both histories become unreadable.
• Count reopens. A defect reopened twice says something about the fix process — no test added, no review, an unclear expected result — not only about that defect.
• Turn the confirmation steps into an automated test at the lowest level that can express them, so the defect cannot return silently.

Try it: Regression Scenario Generator

Worked example: one defect from discovery to closure

The following is a fictional defect in a fictional retail app, with realistic data. Prices are in Saudi riyals with 15% VAT, and the product rule in this example is that VAT is charged on the price after the discount.

• Triage raised the severity from Major to Critical because the team's scale puts wrong payment amounts in Critical — severity follows the scale, not the reporter's first guess.
• The reopen was legitimate: the same underlying defect showing on a second screen. A different symptom would have been a new, linked record.
• Verification used the stated build and varied the coupon type and the platform instead of repeating only the original steps.
• The record carries what metrics need later: when and where it was found, age, reopen count and root cause origin.

DEF-2417  Android checkout charges 190.00 SAR instead of 184.00 with a fixed-amount coupon
Found in: system testing, release 5.3.0     Reporter: layla.h@example.com
Environment: Android app 5.3.0 (build 530-rc2), Android 14 emulator, staging, API v2

2026-09-14 09:40  NEW          Cart 200.00 SAR, coupon SAVE40 (-40.00). Expected (200 - 40) x 1.15 = 184.00.
                               Actual: charged 190.00 (VAT 30.00 computed on 200.00, then -40.00).
                               Web checkout, same account: correct. Request and response attached.
                               Reported severity: Major.
2026-09-14 14:00  OPEN         Triage: reproduced 3/3 by a second tester; no duplicate ("VAT", "coupon").
                               Severity raised to Critical (customer charged a wrong amount).
                               Priority Highest (release 5.3.0 due 2026-09-21).
                               Owner: omar.k (payments API). Target: 5.3.0.
2026-09-15 10:15  IN PROGRESS  API v2 POST /orders/price applies the coupon after VAT; v1 was changed
                               in 5.1 when the rule changed, v2 was not.
2026-09-15 17:30  RESOLVED     Fixed in build 530-rc3. API tests added for fixed and % coupons.
2026-09-16 11:05  REOPENED     Retest on rc3: amount charged is 184.00, but the order summary before
                               payment still shows 190.00 (GET /orders/summary, v2). Same defect.
2026-09-16 11:20  OPEN         Back to omar.k with the retest evidence. Target unchanged: 5.3.0.
2026-09-16 13:40  IN PROGRESS  GET /orders/summary (v2) still calls the old pricing function.
2026-09-16 18:20  RESOLVED     Fixed in build 530-rc4: summary uses the corrected pricing function.
2026-09-17 12:40  VERIFIED     Confirmation on rc4: 184.00 on both screens; also 20% coupon, web and
                               Android. Regression: checkout and pricing pack 38/38 passed.
2026-09-21 16:00  CLOSED       Shipped in 5.3.0.

Age at verification: 3 d 3 h   Reopen count: 1   Found in: system test
Root cause origin: requirements (rule change scoped to web only); contributing: code, test

Try it: HTTP Request Inspector Try it: API Response Analyzer Try it: AI Bug Description Generator

Defect aging, defect metrics and summary reports

Defect age is the time a defect has been open: from creation to now for open defects, or to resolution or closure for finished ones — pick one definition and keep it. Time in each state is more useful than total age, because it shows where defects wait: days in New mean triage is not happening; days in Resolved mean the retest queue is the bottleneck; days in Needs info mean reports are missing facts.

A handful of defect metrics support real decisions: open defects by severity and age (release readiness), arrivals versus closures over time (is the backlog converging?), reopen rate (fix quality), rejected and duplicate rate (report quality and tracker search), and the share of defects found in each stage compared with production — the idea behind defect detection percentage in the ISTQB glossary. The test metrics guide covers the definitions, formulas and how metrics get gamed.

A defect summary report presents this to people who do not live in the tracker, usually as part of a test progress or test completion report. It gives counts and trends, and names the specific open defects that affect the release decision, each with severity, priority, owner and plan.

• Set age thresholds per severity — for example, a Critical defect untriaged after one working day, or a Major defect in Resolved for more than three days — and review breaches every week.
• Report deferred defects explicitly; a deferred defect is a known risk in the release, not a closed one.

Defect summary - release 5.3.0 - week ending 2026-09-18
Open by severity:     Blocker 0 | Critical 1 | Major 6 | Minor 14 | Trivial 9   (total 30)
Arrivals / closures:  23 / 31 this week (backlog down 8)
Age of open defects:  under 7 d: 18 | 7-30 d: 9 | over 30 d: 3 (all Minor, deferred to 5.4)
Reopen rate:          3 of 58 fixes in the last 4 weeks (5%)
Found in:             reviews 11 | system test 37 | UAT 6 | production 2
Release-relevant:     DEF-2451 Critical / Highest / omar.k - fix in rc5, retest 2026-09-19
Deferred, risk accepted by product owner on 2026-09-17: DEF-2290, DEF-2304

Running the lifecycle well: a checklist

AI assistance fits the text-heavy steps of the lifecycle: turning rough notes into a structured report, proposing a searchable title, suggesting severity and priority with a justification, and explaining a stack trace. Treat the output as a draft: the tester confirms it, and triage owns the final severity and priority.

• One tracker and one documented workflow per product, with a mapping to the generic states.
• Every state has an owner and an exit condition; required fields enforce the important ones.
• A fixed triage cadence, and the untriaged queue kept close to empty.
• A mandatory reason for every non-fix resolution, with duplicates linked.
• Every fix states its build; every retest happens in that build; regression scope comes from the diff.
• Record where each defect was found and its root cause origin, so escapes can be measured.
• Review aging, reopen rate and the deferred list every week during a release.

Try it: AI Bug Title Generator Try it: AI Bug Description Generator Try it: AI Bug Severity Suggestion Try it: AI Bug Priority Suggestion Try it: AI Error Message Analyzer

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• IEEE 1044-2009 — IEEE Standard Classification for Software AnomaliesIEEE Standards Association · 2009A standard vocabulary and attributes for classifying software anomalies — defects, failures and their impact (listed by IEEE as inactive-reserved).
• Editing a Bug (section "Life Cycle of a Bug") — Bugzilla DocumentationBugzilla Project (Mozilla)A widely used tracker's default bug workflow — statuses, resolutions (fixed, invalid, won't fix, duplicate, works for me) and transitions — as a concrete lifecycle example.
• ISO/IEC/IEEE 29119-3:2021 — Software and systems engineering — Software testing — Part 3: Test documentationISO/IEC/IEEE · 2021Templates and content for test documentation — test policy, strategy, plan, status and completion reports, incident reports.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024ISTQB's advanced syllabus on managing testing: test planning and estimation, risk-based testing, monitoring, metrics and reporting.