Topics in this domain
- Project Roles and Governance
- PMBOK Phases
- Gantt, PERT, Critical Path
- Function Point Analysis
- Earned Value and Project Risk
- Business Case and Feasibility
- Benefits Realization
- SDLC Phases Overview
- Requirements Definition
- System Design
- Waterfall vs. Iterative vs. Prototyping
- Agile
- DevOps and DevSecOps
- RAD, CASE, Low-Code
- Build, Coding Standards, Code Review
- Testing Levels: Unit, Integration, System, UAT
- Regression, Sociability, Parallel, Pilot Testing
- Defect Management
- Data Migration and Conversion
- Change-Over: Parallel, Phased, Abrupt
- Go-Live Readiness and Acceptance
- Post-Implementation Review
- Input Controls
- Processing Controls
- Output Controls
- Data Integrity and ACID
- EDI and E-Commerce Controls
Defect Management
A snagging list for software
When you buy a new flat, you walk round with a snagging list: cracked tile, door that sticks, missing socket. The builder fixes each one, and you check it yourself before you tick it off. You don’t just take the builder’s word for it.
Defect management is the same discipline for software. Every bug found in testing is written down, fixed, checked, and only then closed.
Logging a defect
Each defect is recorded in a tracking system with:
- a description and steps to reproduce it
- the environment and the test case that found it
- severity: how much damage it does (critical, high, medium, low)
- priority: how urgently it needs fixing
- an owner, a status, and a history of what happened to it
Severity vs priority
They sound alike, but they’re different:
- A misspelt company name on the login page is low severity (nothing breaks) but high priority the day before launch.
- A crash in a year-end report is high severity, but if year-end is months away it can be lower priority in this release.
The life cycle
- Log the defect.
- Triage: is it real? Set its priority and assign an owner.
- Fix it in the development environment.
- Retest the fix, and regression test related functions to make sure nothing else broke.
- Close it: done by the tester or user who raised it, not by the developer who fixed it.
Deferred defects are documented, and their risk is understood.
Going live with open defects
Test exit criteria should say how many open defects are acceptable, for example zero critical and no more than a few high ones with workarounds. If the business decides to go live with known defects anyway:
- workarounds are documented and communicated
- the business owner formally accepts the risk
- fixes are scheduled
Defects found after go-live aren’t tracked in the project defect log. They go through incident, problem and change management.
Reading the numbers
- Discovery rate: new defects per day or week. If it’s falling while testing effort stays the same, the system is stabilising. If testing effort dropped too, it means nothing.
- Ageing: how long defects stay open.
- Reopen rate: fixes that didn’t actually fix the problem.
- Defect density: defects per module or function point.
Example. Two days before go-live, the defect log shows 4 open critical defects, all marked “fixed” by developers but not yet retested. The steering committee’s dashboard shows “0 open critical” because it counts “fixed” as closed. The auditor recommends counting only retested defects as closed, and delaying the go/no-go decision until retesting is done.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Who should close a defect | The tester or user, after retest |
| What follows a defect fix | Retest plus regression testing |
| Going live with critical defects | Only with a documented workaround and business risk acceptance |
| Difference between severity and priority | Impact vs urgency |
In short
- Every defect found in testing is logged with severity, priority, steps to reproduce, owner and status.
- Severity reflects impact on the system; priority reflects how urgently it must be fixed.
- Fixes are retested, and regression testing confirms nothing else broke.
- Go-live decisions consider open defects; critical defects normally block release unless a documented workaround and risk acceptance exist.
- Defect trends (discovery rate, ageing, reopen rate) indicate quality and readiness.
- Defects should be closed only by testers or users, not by the developer who fixed them.
Exam traps
- A developer closing their own defect without retest is a control weakness.
- Going live with known critical defects requires formal risk acceptance by the business owner.
- A falling count of open defects can mean testing slowed down, not that quality improved.
- Defects found in production go through incident, problem and change management, not the project defect log.
Slides
Click the slide and use the arrow keys. F toggles full screen.
The defect life cycle
Severity vs priority