Test Lead · Management Technique

Defect Management

From discovery to closure. Defect management is the process of tracking, triaging, and fixing bugs systematically. It's how we ensure that problems don't just get "lost in the noise."

Test Lead ISTQB CTFL Ch. 5 — K3 Apply ~22 min read + exercise

1 The Hook — The "Ghost" Bug

You find a bug. You tell a developer. They say "Oh, I'll fix that later." Two weeks later, the bug is still there, nobody remembers how to reproduce it, and the client just saw it in a demo. This is the Ghost Bug.

Without a formal process, bugs become ghosts that haunt your project. Defect Management is the process of putting every ghost into a box (A Ticket) and assigning it a fate (A Status).

2 The Rule — Severity vs. Priority

Severity measures technical impact; Priority measures business urgency.

  • Severity: How badly is the system broken? (e.g. Crash = Critical).
  • Priority: How fast do we need to fix it? (e.g. Fix before 5pm = P1).
  • The Lead's Job: Defend the Severity, but collaborate on the Priority.

3 The Analogy — The Police Investigation

Analogy

Evidence vs. Conviction.

The **Tester** is the **Detective**. Your job is to gather the **Evidence** (Logs, Screenshots, Steps) to prove a crime (The Bug) happened. The **Developer** is the **Lawyer** who might try to say "It's not a crime, it's a feature." The **Test Lead** is the **Police Chief** who decides which cases are high-priority and which ones get "closed" without further action. If your evidence is weak, the Lawyer will get the case thrown out (Rejected).

4 Watch Me Do It — NZ Banking Triage

Scenario: You've found 3 bugs in the new "Kiwibank" mobile app. You need to triage them.

  • Bug 1: App crashes when trying to transfer $1,000,000. Triage: Severity: Critical (Crash), Priority: P3 (Rarely happens).
  • Bug 2: The Kiwibank logo is upside down on the home screen. Triage: Severity: Low (Cosmetic), Priority: P1 (Huge reputational damage).
  • Bug 3: The "Help" link goes to a 404 page. Triage: Severity: Medium (Functionality broken), Priority: P2 (High traffic page).

5 Decision Tool — The Bug Lifecycle

StatusMeaning
NewReported but not yet verified by the Lead.
AssignedConfirmed as a bug and given to a Developer.
FixedDev claims it's gone. Ready for re-test.
VerifiedThe Tester confirms it's actually fixed. Success!
Rejected"Not a bug" or "Works as designed."

6 Common Mistakes

🚫 "It's not working" (Vague reports)

I used to think: The dev knows what I mean.
Actually: If you don't include **Steps to Reproduce**, the dev will waste 2 hours trying to find it and then "Reject" it. Always include: 1. Start here, 2. Click this, 3. See that.

🚫 Conflating Severity and Priority

I used to think: Every crash is a P1.
Actually: A crash in a feature that nobody uses is a P3. A typo on the homepage is a P1. You must separate the **Technical Impact** from the **Business Urgency**.

7 Now You Try — Assign the Status

🎯 Interactive Exercise

Scenario: You've just re-tested a bug and it's still broken.

What should you change the status to?

Never move a bug back to "New"; it must be "Re-opened" to show it failed re-testing.

8 Self-Check

Q1. What is a "Triage Meeting"?

It is a meeting between the Test Lead, Dev Lead, and Product Owner to review all "New" bugs and decide which ones will be fixed in the current sprint.

Q2. What is "Root Cause Analysis" (RCA)?

It is looking deeper than the bug. If we found a typo, was it because the dev can't spell? Or was it because there is no automated spell-check in our build pipeline? RCA fixes the process, not just the bug.

9 Interview Prep

"How do you handle a developer who rejects your bug saying 'it works on my machine'?"

Answer: "I don't argue; I provide better evidence. I record a video of the bug happening in the Test environment, and I include the specific browser version and data I was using. If it still doesn't work for them, I offer to sit with them and show them in person. If we still disagree, I take it to the Triage meeting for a final decision."