Defect Management Done Right

This post is part of the ISTQB Foundation Level series. If you missed the previous post, read Part 9 — Test Management first.

Introduction — The Defect as a Communication Artefact

A defect report is not a complaint. It is not a note to yourself. It is a communication artefact — a contract between the tester who found a problem and the developer who needs to fix it.

When a defect report is vague, incomplete, or misleading, one of three things happens: the developer cannot reproduce it and marks it “Cannot Reproduce”, the wrong thing gets fixed, or the report sits in the backlog for weeks because nobody has the context to act on it.

Poor defect reports slow teams down, erode trust between QA and development, and let defects stay in production longer than necessary. Great defect reports do the opposite: they give developers everything they need to reproduce, understand, and fix the problem with minimal back-and-forth.

This post covers everything you need to write defect reports that actually get fixed — the ISTQB defect lifecycle, the critical distinction between severity and priority, anatomy of a great report, and the common anti-patterns that make reports useless.

The Defect Lifecycle — ISTQB 5.6

ISTQB defines the defect lifecycle (also called the defect management process or cykl życia defektu in Polish) as the set of states a defect passes through from discovery to closure.

The standard lifecycle looks like this:

[New] → [Assigned] → [In Progress] → [Fixed] → [Ready for Test]
                                                       ↓
                                                  [Verified]
                                                       ↓
                                                  [Closed]

Side paths:
[New]         → [Rejected]   (not a real defect)
[In Progress] → [Deferred]   (real defect, intentionally not fixed now)
[Verified]    → [Reopened]   → [In Progress]

Let’s walk through each state:

New — The defect has been reported and entered into the defect tracking system. It has not yet been assigned to anyone. This is the entry state for every new report.

Assigned — A developer (or team lead) has been assigned responsibility for investigating and fixing the defect.

In Progress — The developer is actively working on the fix.

Fixed — The developer believes the defect is resolved and has submitted the fix. The code change is ready for verification.

Ready for Test — The fix has been deployed to the test environment and is waiting for the tester to verify it.

Verified — The tester has confirmed that the fix resolves the defect as reported. This is distinct from Closed — verified means “the fix works”, not “we’re done”.

Closed — The defect has been verified and all parties agree it is resolved. This is the terminal state.

Rejected — The defect is not a real defect. It may be a misunderstanding of requirements, expected behaviour, a duplicate, or a configuration issue. Rejected defects should include a clear explanation.

Reopened — A defect that was Verified or Closed is found to recur. It re-enters the lifecycle at an appropriate state, typically In Progress or Assigned.

Deferred — The defect is real and acknowledged, but a deliberate decision has been made not to fix it in the current release. Deferral requires stakeholder approval — it is not a developer’s unilateral decision. Common reasons: the affected area is being deprecated, the business impact is low relative to the fix risk, or the release date is imminent. Deferred defects must be revisited in the next planning cycle.

:::danger[Verification is not optional] Never close a defect without verification by someone other than the developer who fixed it. A developer verifying their own fix is a conflict of interest and a process failure. The whole point of the Verified state is an independent check that the fix actually works. :::

Severity vs Priority

This is one of the most frequently misunderstood topics in defect management — and a reliable ISTQB exam topic.

Severity — Set by QA

Severity (ISTQB: Waga) describes the impact on the system. It is a technical measure of how badly the defect breaks things. Severity is determined by the tester or QA team.

Severity	Definition	Example
Critical	System crash, data loss, complete feature failure with no workaround	Payment processing returns HTTP 500 for all users
High	Major feature does not work, workaround is awkward or impacts many users	File upload silently fails for files > 5 MB
Medium	Feature works but incorrectly or incompletely; workaround exists	Date picker shows wrong year in February on leap years
Low	Cosmetic issue, minor inconvenience, no functional impact	Button text is truncated on Safari at 110% zoom

Priority — Set by the Product Owner

Priority (ISTQB: Priorytet) describes the business urgency — how quickly the defect needs to be fixed relative to other work. Priority is determined by the product owner or business stakeholder, not by QA.

When They Diverge

The interesting cases — and the ones that appear on the ISTQB exam — are when severity and priority point in different directions:

High severity, Low priority — A critical crash occurs in a rarely-used legacy feature that is scheduled for removal next quarter. The system is broken, but nobody is going to fix it right now.

Low severity, High priority — The CEO’s name is misspelled on the “About Us” page. Technically a cosmetic issue (low severity). But the CEO noticed it this morning, so it gets fixed before lunch (high priority).

Critical severity, Deferred — A deprecated API endpoint returns corrupted data. Critical if called, but the endpoint is being removed in two weeks and has zero active callers. Deferred with stakeholder approval.

:::tip[ISTQB Exam Tip] The exam loves scenarios where you have to distinguish severity from priority. Remember: severity is about technical impact (QA sets it), priority is about business urgency (PO/stakeholder sets it). A critical severity bug can have low priority, and a low severity bug can have high priority. These are independent dimensions. :::

Writing Great Defect Reports

The Full Template

Title:            [Page/Feature] - Short description of symptom
Environment:      OS, browser, app version, user role, test data
Severity:         Critical / High / Medium / Low
Priority:         High / Medium / Low
Steps to Reproduce:
  1. Navigate to /checkout
  2. Add item to cart
  3. Click "Proceed to Payment"
  4. Enter card number: 4111111111111111
  5. Click "Pay"
Expected Result: Payment processes successfully, redirect to confirmation page
Actual Result:   Error 500 returned, payment not processed
Attachments:     screenshot.png, network_log.har

Let’s go through what makes each field valuable.

Title Quality

The title is the first thing a developer reads. It needs to tell them the feature, the condition, and the symptom — all in one line.

Bad title: it doesn't work
Nobody knows what “it” is, what “doesn’t work” means, or under what conditions.

Slightly better: Payment fails
Better, but still vague. What kind of payment? What kind of failure? When?

Good title: Checkout — Payment fails with Visa cards on mobile (HTTP 500)
This tells the developer: the feature (Checkout), the condition (Visa cards on mobile), and the symptom (HTTP 500). They can search logs, find the relevant code path, and start investigating before reading another word.

The format [Feature/Page] — [Condition] — [Symptom] is a reliable template for clear titles.

Steps to Reproduce

Steps to reproduce are the most important part of the defect report. If a developer cannot reproduce the defect, they cannot fix it.

Rules for great steps to reproduce:

Number every step — makes it easy to reference (“fails at step 4”)
Each step should be atomic — one action per step, no bundling
Include the starting condition — what state is the system in before step 1? Fresh login? Specific user role? Specific data?
Include test data explicitly — don’t say “enter a card number”, say “enter 4111111111111111 (Visa test card)”
Be precise about navigation — “Go to checkout” is vague; “Navigate to /cart and click ‘Proceed to Checkout’” is precise

Expected Result

The expected result should ideally reference a requirement, user story, or specification. “Expected: payment succeeds” is obvious and unhelpful. “Expected: payment processes successfully and user is redirected to /confirmation with order ID displayed (per AC-3 in US-142)” gives the developer context and a reference to verify against.

Reproducibility

State the reproducibility percentage and conditions. “Reproducible 100% of the time” vs “Reproducible 3/5 attempts, always on Chrome, never on Firefox” vs “Reproduced once, could not reproduce subsequently” all have completely different implications for how the developer investigates.

Defect Triage

Defect triage is the process of reviewing new defects to assign severity, priority, ownership, and target release.

Cadence: Typically daily for active projects, or at the start of each sprint planning cycle.

Participants: Test lead or QA representative, product owner, development lead, optionally: release manager or project manager.

Agenda:

Review all defects in “New” state since last triage
Confirm or adjust severity (set by QA on report)
Assign priority (product owner)
Assign to developer or team
Decide: fix in current sprint, defer, or reject

Output: Every New defect exits triage with a state (Assigned, Deferred, or Rejected), an owner, and a priority. No defect should leave triage in an ambiguous state.

Triage meetings should be time-boxed. If a defect requires significant discussion about root cause or approach, that discussion happens outside the triage meeting.

Root Cause Analysis

Fixing a defect removes a symptom. Root cause analysis (RCA) identifies why the defect occurred so the underlying cause can be addressed — preventing the same class of defect from recurring.

The 5 Whys Technique

The 5 Whys is a simple, iterative technique for drilling down to root cause:

Problem: Payment fails with Visa cards on mobile.

Why? — The payment API returns HTTP 500.
Why? — The card number formatter strips hyphens before sending to the API.
Why? — The formatter was written for desktop input (no hyphens) and not updated when mobile input was added.
Why? — There was no test case covering mobile card input format.
Why? — Test coverage for the payment module’s input handling was never defined in the test plan.

Root cause: Missing test coverage definition for payment input handling across input types.

Fix at root cause: Add test coverage requirements for payment input to the test strategy. The code fix is necessary, but alone it does not prevent the same class of defect.

Defect Categories

Categorizing defects (requirements defect, design defect, code defect, test data defect, configuration defect, etc.) lets you spot patterns. If 40% of your defects in the last quarter were “requirements defects”, you have a requirements process problem, not a code quality problem.

Use RCA data to improve your process: update checklists, improve code review guidelines, add test coverage rules, or address upstream ambiguity in requirements.

Common Anti-Patterns

“Can’t Reproduce” as a resolution — Used when the developer doesn’t have the right environment, test data, or context. The fix: require developers to document what they tried before marking Cannot Reproduce, and have QA and dev pair up to reproduce together.
Closing without verification — The developer fixes it, marks it closed, and the tester never validates. The fix: enforce the Verified state as a required step before Closed.
Conflating severity and priority — The developer sets priority based on how hard the fix is. QA sets severity based on business impact. Product sets priority based on business urgency. Each role should own their field.
Vague expected results — “Expected: it works” is not a requirement. If you can’t state what correct behaviour looks like, you don’t have enough information to write the report.
No environment information — Half the defects that say “always reproducible” disappear because the environment information was missing. Always include OS, browser version, app version, and any relevant configuration.

Conclusion

Defect management is one of the highest-leverage skills in QA. A great defect report accelerates the entire fix cycle: the developer understands the problem immediately, the fix is targeted and correct, verification is unambiguous, and the defect is closed with confidence.

Action for this week: Pull up 5 recent defect reports from your project and evaluate each one against the template in this post. How many have complete steps to reproduce? Clear expected results? Explicit environment information? The gaps you find will tell you exactly where your defect reporting process needs improvement.

The ISTQB foundation syllabus covers defect management in section 5.6. The key terms to know: defect lifecycle (cykl życia defektu), severity (Waga), priority (Priorytet), deferred (acknowledged defect intentionally not fixed in the current release), and root cause analysis.

Next up: Part 11 — Test Tools, Automation ROI, and Risks