A defect is not fixed: it is managed. That is the short answer to why a bug life cycle exists. When a tester finds a failure, it is not enough to raise a flag and hope someone corrects it. The defect enters a flow of states with clear rules: who owns it, what is expected of that person, and when it can truly be considered closed. Skipping that flow is the most common way a bug marked as "fixed" reappears in production two weeks later.
The life cycle of a defect is, at heart, a contract between three roles: whoever reports, whoever corrects, and whoever verifies. Each state of the defect says whose court the ball is in right now. If nobody knows whose court the ball is in, the defect drifts, and drifting defects are the ones that reach the customer.
01 · the mapWhat the life cycle is and why it exists
The ISTQB defines a defect as an imperfection in a component or system that can cause it to fail to perform its required function. Defect management, according to its glossary, is the process of recognizing, recording, classifying, investigating, resolving, and disposing of defects [1]. That list of verbs is already, almost word for word, the life cycle: each verb corresponds to a state the defect passes through.
The underlying reason is simple. A loose defect has no owner and no memory. A defect inside a flow of states always has a current owner and a record of where it has been. That turns an informal complaint into a traceable unit of work, one that can be measured, prioritized, and audited.
Each state of the defect answers a single question: right now, whose court is the ball in?
It helps not to confuse two things that sound alike. Severity measures how much damage the defect does to the system. Priority measures how urgently it must be corrected from the business point of view. A typo in the logo may be low severity but high priority if it goes on the front page tomorrow. The life cycle is independent of both: a trivial defect and a critical one travel through the same states, only at a different speed.
02 · the statesFrom 'new' to 'closed', step by step
The exact names change between tools like Jira, Bugzilla, or Azure DevOps, but the skeleton is nearly universal. These are the states worth understanding.
New. The defect has just been reported. Half the game is played here: a good report brings steps to reproduce, expected result, actual result, environment, and evidence. A poor report condemns the defect to bounce around in "need more information" for days.
Assigned. Someone, almost always a technical or QA lead, checks that the defect is valid and assigns it to whoever should correct it. Here the ball passes from QA to development.
In progress. The developer is working on the correction. The defect has an owner and is on the move.
Resolved. The code has been corrected, but watch out: resolved is not closed. It is a claim by one party that the other has not yet checked. The ball goes back to QA.
Verified. QA runs the scenario again and confirms that the defect no longer occurs. This is the line that separates serious testing from "trust me, I already fixed it".
Closed. The defect is considered finished. You only get here after verifying, not before.
Reopened: QA verifies, the defect is still there, and the flow returns to correction instead of closing on false pretenses. Rejected or duplicate: the defect was not valid, cannot be reproduced, or an identical one already existed. Without these detours, the board fills with "closed" defects that were in fact never checked, and with duplicates that inflate the metrics.
03 · the critical pointWhy verification is not optional
The most fragile moment of the cycle is the jump from "resolved" to "closed". It is tempting to close as soon as development says it is done, especially when the delivery date is pressing. But closing without verifying breaks the entire contract. A resolved defect is a hypothesis; a verified defect is a fact.
The distinction connects to something bigger: the difference between verifying and validating. Verifying answers "was what we said we would correct actually corrected?". Validating answers "does this solve the user's real problem?". Closing a defect is, in miniature, an act of verification, and that is why the person who made the fix cannot skip it.
There is an added reason to take this stage seriously: correcting one defect can introduce another. That is what is called a regression defect. This is why a mature verification not only checks that the original bug is gone, but also reviews that nothing nearby was broken in the attempt. That is where defect management links up with the regression testing strategy.
04 · the boardWhat a healthy cycle measures
When the life cycle works, the defect board starts to tell useful things. The reopen rate reveals whether the fixes hold or whether they close on false pretenses. The time in each state shows where defects get stuck: if they live for days in "new", the problem is triage; if they live for days in "resolved", the bottleneck is verification. The defect density per module points to which part of the product concentrates the risk.
None of this is possible without disciplined states. A defect that jumps straight from "new" to "closed" leaves no trace to measure. The life cycle is not bureaucracy: it is the condition for the team to learn from its own mistakes instead of repeating them.
Next time someone says "I already fixed the bug", it is worth asking what state it is in. If the answer is "resolved", the work is not done yet. Only when someone other than the person who corrected it looks again, runs the scenario, and confirms that the failure is gone can the defect move from new to closed without losing it along the way.
Sources
- ISTQB (International Software Testing Qualifications Board). Standard Glossary of Terms Used in Software Testing. Definitions of "defect" and "defect management". glossary.istqb.org.
- ISTQB. Certified Tester Foundation Level (CTFL) Syllabus, v4.0 (2023). Section on defect management, reporting, and the defect life cycle. istqb.org.
- IEEE. IEEE Std 1044-2009: Standard Classification for Software Anomalies. Classification of software anomalies and their processing by states. IEEE Standards Association.
- ISO/IEC/IEEE 29119-1. Software and systems engineering. Software testing. Part 1: General concepts. Incident and defect management within the testing process. iso.org.