Defect and Bug Life Cycle Interview Questions

Overview

The bug life cycle is the most predictable topic in a QA interview, which is exactly why fumbling it hurts so much. If you cannot walk a defect from the moment it is logged to the moment it is closed, naming the states and who owns each transition, the interviewer quietly concludes you have never actually managed defects in a real tool. This guide makes that walk automatic and then pushes past the states into the parts that separate strong candidates: severity versus priority, triage, and the metrics leaders care about.

It is written for QA testers and analysts who log, track, and report defects as a daily job. Rather than a flat list of statuses, it treats the defect life cycle the way interviewers do: as a workflow with a happy path, a set of exception branches, and a governance layer of triage and metrics on top. Every answer is phrased to be delivered out loud, with the state, the owner of the transition, and the reason the state exists.

Deliver the states as a story, not a glossary. When asked to explain the bug life cycle, narrate a single defect moving through the workflow, because that proves you understand the transitions and who drives them, not just the labels. Then be ready to branch: what happens when a developer rejects it, when it duplicates another report, or when it cannot be reproduced. Those branches are where the interesting questions live.

Why The Defect Life Cycle Dominates QA Interviews

Interviewers rely on this topic because it instantly reveals hands-on experience. Someone who has worked defects in a tracker like Jira speaks about states, assignees, and transitions naturally, while someone who only read about testing recites a diagram without understanding why a defect ever gets rejected or reopened. The workflow is also the shared language between testers, developers, and managers, so knowing it proves you can collaborate inside a real delivery process.

The way to stand out is to show you understand the workflow as a set of ownership handoffs. A defect is never just 'in progress'; at every state a specific role holds it and is responsible for the next move. Testers own logging, retesting, and closing; developers own fixing and sometimes rejecting; leads and triage own prioritization and deferral. Framing the life cycle as a chain of responsibilities, not just statuses, is what makes your answer sound lived-in rather than memorized.

What Is The Defect Life Cycle

Question: what is the defect or bug life cycle? It is the sequence of states a defect passes through from the moment it is discovered and logged until it is finally resolved and closed. Each state represents the defect's current status in the workflow, and each transition is triggered by a specific person taking a specific action. The exact state names vary slightly between organizations and tools, but the underlying flow is standard.

The reason it exists, and a good line to add, is accountability and visibility. The life cycle ensures no defect is lost, that everyone can see where any defect stands and who holds it, and that resolution follows a consistent, auditable path rather than ad-hoc messages. Mentioning that the workflow is usually configured in a defect tracking tool, so the states and allowed transitions are enforced, signals that you have operated inside a real system rather than tracked bugs in a spreadsheet.

The Core States From New To Closed

The happy path is the backbone of your answer, so deliver it fluently. A defect is logged as New. A lead or triage reviews it and, if valid, moves it to Assigned (assigned to a developer). The developer works it and marks it Fixed (sometimes shown as an intermediate Open or In Progress while they work). The build with the fix reaches the tester, who moves it to Retest and re-executes the failing case. If the fix works, the tester marks it Verified and then Closed. That is the clean, everything-goes-right journey.

• New: the tester has just logged the defect; it awaits review.
• Assigned: a lead or triage validated it and assigned it to a developer.
• Open or In Progress: the developer is actively investigating and fixing.
• Fixed: the developer has implemented a fix, pending tester confirmation.
• Retest: the tester re-runs the case on the new build to confirm the fix.
• Verified: retest passed and the defect behaves as expected.
• Closed: the defect is confirmed resolved and the workflow ends.

The Exception States: Rejected, Duplicate, Deferred

The branches are where interviewers dig, because they reveal whether you understand real defect governance. A defect can be marked Rejected when the reviewer decides it is not a valid defect, for example it describes intended behavior or a misunderstanding of the requirement. It can be marked Duplicate when the same issue is already logged, in which case it is linked to the original and closed. It can be marked Deferred when it is a valid defect but a decision is made to fix it in a later release rather than now, usually because its severity and priority do not justify holding the current release.

Two more branches complete the picture. Not a Bug (or Not Reproducible) is used when the developer cannot reproduce the reported behavior, which sends the defect back to the tester for more information or evidence rather than to a fix. And a Reopened state exists for when a supposedly fixed defect fails retest or resurfaces later. Being able to name each exception state and the exact reason a defect lands there is the difference between reciting the happy path and demonstrating you have handled defects that did not go smoothly.

Walk Me Through A Bug's Journey

A very common instruction is simply 'walk me through the life of a bug you found'. Turn it into a concrete narrative. You find that a discount code applies twice on a specific cart, so you log it as New with steps, data, and a screen recording. Triage reviews it, agrees it is valid and high impact, and moves it to Assigned. The developer investigates, finds a missing idempotency check, fixes it, and marks it Fixed in the next build.

You pick up the build, move the defect to Retest, and re-run the exact failing scenario plus a couple of neighboring cases to be safe. The double discount is gone, so you mark it Verified and Closed, and you add the scenario to the regression set so it cannot silently return. If the fix had failed retest, you would have Reopened it with the new evidence instead. Telling it as a story, with the specific action at each state, is far more convincing than listing the states in the abstract.

Severity vs Priority: The Marquee Contrast

No defect topic is asked more than this one, so own it. Severity measures the technical impact of the defect on the system: how badly it breaks functionality, from cosmetic up to a crash or data loss. Priority measures the business urgency of fixing it: how soon it needs to be addressed relative to other work. They are independent axes, which is the entire point of the question, and the way to prove you understand it is with the four combinations.

Give a crisp example for each quadrant. High severity and high priority: the checkout crashes on payment, a showstopper that blocks release. High severity and low priority: the application crashes on a rarely used legacy report that almost no one opens, serious but not urgent. Low severity and high priority: the company name is misspelled on the homepage banner, trivial technically but urgent for brand reputation. Low severity and low priority: a tooltip has a minor typo on an internal admin screen. Walking all four quadrants with concrete examples is the definitive strong answer.

Who Sets Severity And Priority, And Defect Triage

A natural follow-up: who decides severity and who decides priority? Severity is typically set by the tester, because it reflects the technical impact they observed. Priority is usually set by the project lead, product owner, or triage team, because it reflects a business decision about scheduling. This split is worth stating plainly, since candidates often assume one person sets both.

That leads into triage. Question: what is defect triage? It is a meeting where stakeholders, usually the test lead, development lead, and product owner, review new and open defects to validate them, confirm severity, assign priority, and decide what gets fixed now, deferred, or rejected. The purpose is to make prioritization a deliberate, shared decision rather than first-come-first-served. Mentioning that triage balances risk against release timelines, and that it is where deferral decisions are made, shows you understand the governance layer sitting above the raw workflow.

What Goes Into A Defect Report

Interviewers check whether your reports carry the metadata the workflow needs. Beyond the reproduction essentials (summary, steps, actual versus expected, environment, and evidence), a well-formed defect carries the classification fields that drive triage and metrics: a unique defect ID, the current status, the assignee, severity, priority, the defect type or category, and the phase in which it was detected. Some teams also capture the phase in which it was injected, which feeds root cause analysis.

The point to make is that these fields are not bureaucracy; they are what make defects sortable, assignable, and measurable at scale. A tracker full of defects with severity and type filled in lets a lead answer questions like 'how many high-severity UI defects are open this sprint' in seconds. If asked what makes defect data useful beyond a single bug, this is the answer: consistent classification turns a pile of individual reports into metrics a team can act on.

Defect Metrics Interviewers Ask About

Mid and senior rounds move from a single defect to defect analytics. Be ready to define the common metrics precisely, because vague answers here are obvious. Defect density is the number of defects per size of module or code, used to spot the buggiest components. Defect removal efficiency (DRE) is the percentage of defects found before release out of all defects (including those found by users after release), a core measure of how effective your testing was.

Two more come up often. Defect leakage (or defect escape rate) is the proportion of defects that slipped past testing and were found in production, the inverse concern to DRE. Defect age is how long a defect stays open from detection to closure, and reopen rate is the percentage of fixed defects that failed retest and came back, a signal of fix quality or unclear reports. Being able to state the formula intent for each, not just the name, is what makes this section a differentiator.

• Defect density: defects divided by module size, to find the buggiest areas.
• Defect removal efficiency: defects found before release as a percentage of all defects found.
• Defect leakage: percentage of defects that escaped to production.
• Defect age: time a defect stays open from detection to closure.
• Reopen rate: percentage of fixed defects that failed retest and reopened.

The Reopened State And Why Bugs Return

Question: why does a defect get reopened, and what does a high reopen rate tell you? A defect is reopened when it was marked fixed but fails retest, or when it was closed and the same issue resurfaces in a later build. The immediate cause is usually an incomplete fix, a fix that addressed a symptom rather than the root cause, or a regression where a new change reintroduced the problem.

A consistently high reopen rate is a process smell worth naming. It often points to fixes made without reproducing the defect, unclear or incomplete defect reports that led developers to fix the wrong thing, or missing regression coverage. If asked how you would reduce it, suggest requiring reproduction before a fix is claimed, tightening report quality, and adding a regression test for every closed defect so a reintroduction is caught automatically. Turning a metric into a concrete corrective action is exactly the reasoning senior interviewers want to see.

Scenario Questions On Defect Management

Panels test judgment with realistic friction. Question: a developer marks your defect as Rejected saying it works as designed, but you believe it is a real bug. What do you do? You do not escalate emotionally. You revisit the requirement or acceptance criteria to confirm the expected behavior, reproduce with clear evidence, and if the requirement genuinely supports your view, reopen the defect with that reference. If the requirement is ambiguous, you take it to the product owner for a ruling. The resolution is driven by the specification and user impact, not by who argues hardest.

Another common one: it is two days before release and testers are logging a flood of defects, how should they be handled? Through triage and severity-priority discipline. You classify each defect, and triage decides which are true release blockers (high severity and high priority), which can ship as known issues, and which are deferred to the next release. The goal is an informed release decision where the residual risk of the open defects is explicitly understood and owned by stakeholders, never a silent gamble.

Root Cause Analysis And Preventing Recurrence

The strongest candidates connect defect management to prevention, so expect a closing question about it. Question: what do you do after a serious defect is closed? Beyond closing the ticket, you look at root cause: not just what broke, but why it was introduced and why testing did not catch it earlier. A simple technique to name is the five whys, repeatedly asking why until you reach the underlying process gap rather than the surface symptom.

The prevention step is what elevates the answer. Based on the root cause, you add a regression test so the specific defect cannot silently return, and you feed the process lesson upstream, for example tightening acceptance criteria if the defect came from an ambiguous requirement, or adding a checklist item if it came from a repeated oversight. Framing defect management as a loop that ends in prevention, not just closure, signals that you see quality as something you improve systematically rather than a queue of tickets you burn down.

Frequently Asked Questions

Related QAJobFit Guides

• Fresher and Entry-Level QA Interview Questions
• Manual Testing Interview Questions and Answers (2026)
• STLC Interview Questions and Answers
• Accenture QA Engineer Interview Questions and Process (2026)
• Accenture SDET Interview Questions and Preparation
• Adobe QA Engineer Interview Questions and Process (2026)