Skip to content

Defect Log

At a glance

  • Purpose: Record every defect found, its severity, and its resolution, so quality can be measured and release decisions made on evidence rather than impressions.
  • Use it when: From the first test cycle to project close. It is the input to the exit criteria in the quality management plan.
  • Owner: The test or quality lead; everyone who finds a defect may raise one.
  • Related: Module 09 · Lab 20 · Lab 22
  • Spreadsheet version: csv/defect-log.csv

How to use this template

  1. Log every defect, including the ones fixed immediately. A log of only the awkward defects distorts the quality picture and destroys its use for estimating.
  2. Set severity by effect on the user or the business, and let the team set priority by urgency. The two are different, and conflating them is why some severe defects get fixed last.
  3. Make a defect reproducible: steps, data, environment, and expected versus actual behaviour. A defect that cannot be reproduced cannot be fixed or closed.
  4. Record the origin — which activity found it. Defects found in review cost far less than the same defects found in production, and the log is what proves it.
  5. Track age and reopen rate. A rising reopen count says fixes are being applied without finding the cause.

Field descriptions

Column What goes in it Watch out for
ID Stable reference (D-001) Reusing IDs
Summary One line describing the observable effect Describing the suspected cause instead
Found in The build, increment, or environment "Testing" with no version
Severity Effect on the user or business (P1–P3, definitions in the quality plan) Severity raised to gain attention
Priority Order of fixing Priority assumed equal to severity without a decision
Steps to reproduce Numbered steps, data, environment "Does not work"
Expected / actual Both stated Only what happened
Origin Which activity found it: review, unit, integration, UAT, production Production findings unrecorded
Cause category Requirements, design, code, configuration, environment, data Cause left as "human error"
Status New / confirmed / in fix / fixed / verified / closed / deferred "Fixed" without verification
Reopen count Times a closed defect was reopened Not tracked, hiding instability

Blank template

# Defect Log — [Project name]

| | |
| --- | --- |
| **Period** | [Start] – [End] |
| **Log owner** | [Who] |
| **Severity definitions** | [Link to the quality management plan] |

| ID | Summary | Found in | Severity | Priority | Steps to reproduce | Expected | Actual | Origin | Cause category | Owner | Status | Opened | Closed | Reopens |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| D-001 | [Observable effect] | [Build / env] | P2 | High | [Numbered steps] | [Behaviour] | [Behaviour] | UAT | Code | [Who] | Verified | [Date] | [Date] | 0 |

## Quality summary for this period

| Measure | Value | Note |
| --- | --- | --- |
| Defects opened | [n] | |
| Defects closed | [n] | |
| Open by severity | P1 [n] · P2 [n] · P3 [n] | Compare against the release exit criteria |
| Found by origin | Review [n] · Unit [n] · Integration [n] · UAT [n] · Production [n] | Earlier origins are cheaper |
| Mean age of open defects | [n] days | |
| Reopen rate | [n]% | A rising rate points to fixes without diagnosis |

## Deferred defects

| ID | Summary | Severity | Why deferred | Risk accepted by | Revisit by |
| --- | --- | --- | --- | --- | --- |

Worked example

From Lab 22, invented figures for teaching — one defect recorded in full:

Field Value
ID D-014
Summary The admin list screen times out when more than about 500 applications are present
Found in Build 0.4, test environment with 1,200 seeded records
Severity P2 — staff cannot review applications during the admission window
Priority High
Steps 1. Seed 1,200 applications. 2. Open the list screen. 3. Wait.
Expected The screen renders within the agreed response target
Actual No response after 60 seconds
Origin UAT with realistic data
Cause category Design — no pagination was specified, and the requirement never stated a record volume
Status Verified closed after the pagination change

And the period summary it contributes to:

Measure Value Note
Defects opened 20 16 found before release, 4 after
Open by severity P1 0 · P2 2 · P3 5 Release exit criteria allow zero P1 and zero P2
Found by origin Review 3 · Unit 5 · Integration 6 · UAT 2 · Production 4 The production group is the expensive one

The last row is the teaching point. The four production defects correspond to items that failed the definition of done earlier, and the cause category for two of them is requirements — not code. A log that records cause honestly turns a list of defects into an explanation of where the project's quality system is weak.

Common mistakes

  • Only logging serious defects. Logging everything is what makes defect density and origin analysis meaningful — and it is cheap.
  • Severity inflated to gain attention. Once everything is P1, the exit criterion "zero P1 open" becomes impossible to satisfy and gets waived.
  • "Fixed" without verification. A defect is closed by a test that reproduces the original failure, not by a developer's confidence.
  • Cause recorded as human error. It stops the investigation where the useful information begins.
  • Not tracking reopens. Reopen rate is one of the few leading indicators of quality you have.
  • Defects deferred with no owner. A deferred defect is an accepted risk and belongs in the register as well as here.
  • No volume context. A defect count means little without the size of the work it came from.