A defect that is not properly recorded, tracked, and managed will be lost, forgotten, or fixed incorrectly
A tester finds a critical payment defect on Friday afternoon and mentions it verbally to the developer. On Monday, neither remembers the exact steps to reproduce it. The developer closes the ticket as "cannot reproduce." The defect ships to production.
Defect management is the process of recording, classifying, prioritising, tracking, and resolving defects from discovery to closure. A well-managed defect is one that can be reproduced, assigned, fixed, verified, and prevented from recurring.
// example: atlassian — defect lifecycle in jira
Defect Management — CTFL 4.0.1
Defect report contents
A well-written defect report contains:
- Unique identifier — reference number for tracking
- Title / Summary — concise description of the defect
- Date and reporter — when found and by whom
- Test item and environment — product version, OS, browser, configuration
- Steps to reproduce — exact, numbered steps to trigger the defect
- Expected result — what should happen per requirements
- Actual result — what actually happened
- Severity and priority — technical impact and business urgency
- Attachments — screenshots, logs, video recordings
Severity vs Priority
Severity — the technical impact of the defect on the system (e.g., Critical, Major, Minor, Trivial). Set by the tester.
Priority — the business urgency to fix the defect (e.g., High, Medium, Low). Set by the product owner or manager.
High severity does not always mean high priority, and vice versa. A minor spelling error on the login page may be Low severity but High priority if it is visible to millions of users during a product launch.
// tip: Exam Tip: Severity and priority are set by different people for different reasons. Severity is a technical assessment (set by the tester or QA team). Priority is a business decision (set by the product owner or manager). The exam frequently presents scenarios where severity and priority diverge — a cosmetic defect on a high-visibility page during a campaign is Low severity, High priority.
Defect Lifecycle — Typical States
| Status | Meaning | Who Acts Next |
|---|---|---|
| New | Defect reported, not yet reviewed | Test manager / developer reviews |
| Assigned | Assigned to a developer for investigation | Developer investigates |
| In Progress | Developer actively working on fix | Developer |
| Fixed | Developer has applied a fix | Tester re-tests |
| Ready for Re-test | Fix deployed to test environment | Tester executes confirmation test |
| Verified | Fix confirmed by tester | Test manager closes |
| Closed | Defect resolved and verified | Process complete |
| Reopened | Fix was incorrect or incomplete | Developer re-investigates |
| Deferred | Valid defect, fix postponed to a future release | Product owner tracks |
| Rejected | Not a defect — expected behaviour or duplicate | Tester reviews and closes or disputes |
New
Defect reported, not yet reviewed
// Possible next states
// Severity vs Priority
Severity = technical impact (set by tester). Priority = business urgency (set by product owner). They can differ: Low severity + High priority = cosmetic issue on high-visibility page.
// Exam tip
"Ready for Re-test" comes AFTER "Fixed" and BEFORE "Verified". The exam will describe a scenario and ask for the next state — know the sequence: Fixed → Ready for Re-test → Verified → Closed.
// Exam trap
"Steps to reproduce are optional in a defect report" is FALSE. Reproducible steps are critical — without them, developers cannot confirm the defect or verify the fix. The exam will test whether you know the essential fields of a well-written defect report.
Severity vs Priority — Key Combinations
| Scenario | Severity | Priority | Reason |
|---|---|---|---|
| Spelling error on homepage during product launch campaign | Low | High | Cosmetically minor but highly visible; damages brand during critical period |
| Crash in a rarely-used admin tool used by 2 internal users | Critical | Low | System crash is severe technically but business impact is minimal |
| Wrong tax calculation on international orders | Major | High | Both technically significant and business-critical |
| Outdated copyright year in footer | Trivial | Low | Cosmetic, low visibility, no business impact |
// warning: Exam Trap: "A defect report without steps to reproduce is acceptable." This is false. Steps to reproduce are one of the most critical elements of a defect report. Without them, the developer cannot reliably reproduce the defect, cannot confirm the fix, and the defect risks being closed as "cannot reproduce." A defect report is only as useful as its ability to be actioned — and that requires reproducible steps.
Exam Practice Questions
// ctfl 4.0.1 style — select an answer to reveal explanation