Defect and Defect Report

A defect is a flaw: the system does not behave as specified. The defect report is how that flaw becomes a managed object — described, prioritised, tracked to resolution or deliberate acceptance. The discipline of defect tracking is the difference between a project that knows its problems and one that discovers them at go-live.

What It Is

A defect (the industry's formal word for a bug) is any deviation of the software from its specified or reasonably expected behaviour. A defect report records: steps to reproduce, expected versus actual behaviour, severity (impact on business: critical, major, minor, cosmetic), priority (urgency of fix), environment and version, and status as it moves through triage, fix, retest and closure. Defects are managed in tracking systems (Jira and equivalents) whose backlogs and burn-down charts become the project's factual heartbeat. Severity is set by impact; priority is a business decision — the two are routinely confused in negotiation.

Why It Matters to You

Defect metrics are the most honest progress signal a project produces — more honest than percent-complete bars. The trends that matter: defects found per week (should eventually decline), defect reopen rate (fixes that didn't fix — a quality signal), and the severity profile of what remains open at each milestone. The commercially loaded moments are triage (vendors downgrade severity; your users upgrade it) and go-live decisions ('known issues' lists are negotiated defect acceptance — read them as such, and get them in writing with fix commitments). Every defect accepted without a fix date is deferred risk wearing a polite name.

When You'll Meet It

From the first delivery onward. You will see defect counts in every status report, and you will arbitrate severity disputes — bring the business impact, not the adjective.