Bug life cycle (defect life cycle) explained

What the bug life cycle is

The bug life cycle, also called the defect life cycle, is the journey a defect takes inside a tracking tool. Each stage is a status, and each status tells the team who owns the bug right now and what needs to happen next.

The exact names vary by tool, but the shape is consistent. A clean life cycle stops bugs from getting lost between the tester who found them and the developer who fixes them.

The core statuses

• New: a tester logs the defect with steps to reproduce.
• Assigned: a lead or manager gives it to a developer.
• Open: the developer begins analysing and fixing it.
• Fixed: the developer has changed the code and marked it done.
• Retest: a tester runs the case again on the new build.
• Verified: the tester confirms the fix works.
• Closed: the defect is resolved and no longer active.
• Reopened: retest failed, so the bug goes back to the developer.

Two extra statuses matter. A bug can be marked Duplicate if it already exists, or Rejected if it is not a real defect, for example when the behaviour matches the requirement.

A bug is not fixed when a developer says it is fixed. It is fixed when a tester verifies it on the real build.

A concrete example

A tester finds that a search box crashes on a very long query. They log it as New with exact steps and a screenshot. The lead moves it to Assigned. The developer reproduces it, sets it to Open, adds a length check, and marks it Fixed. On the next build the tester retests, the crash is gone, and the status moves to Verified then Closed.

Now imagine the fix worked for English text but still crashed on long non-English input. The retest fails, the tester sets the status to Reopened, and the cycle repeats. That single Reopened status is what protects you from shipping a half-fix.

Keeping the cycle clean

The value of the life cycle is not the diagram, it is the discipline. Clear steps to reproduce, honest status changes, and real verification keep the data trustworthy.

• Write steps a developer can follow without asking questions.
• Never close a bug the tester has not verified.
• Protect fixes over time with regression testing.
• Catch defects earlier through manual testing and exploratory sessions.
• Wire the flow into your pipeline with CI/CD test integration.

One honest caveat: a tidy defect board does not mean a healthy product. A team can process bugs quickly and still miss the important ones if test coverage is thin. Counting closed defects is easy, judging which defects matter takes experience. The ISTQB glossary defines these terms if your team needs a shared vocabulary.

At Quality AboveAll, senior testers run the defect cycle with honest status and real verification, so fixed means fixed. If you want a clear picture of your current defect flow, book a free 30-minute testing audit.