Defect (Bug)

A defect (also called a bug, fault, or issue) is a deviation between expected and actual behavior of the software. Defects are discovered during testing or reported by users in production. They represent a gap between what the software should do (per requirements, design, or reasonable user expectations) and what it actually does. While the terms "bug," "defect," "fault," and "issue" are often used interchangeably, some organizations distinguish between them — a "fault" might refer to the code error, while a "defect" refers to the observable incorrect behavior.

Defect attributes that every bug report should include:

• •ID: Unique identifier for tracking and cross-referencing
• •Title: Brief, searchable description that captures the essence of the problem
• •Description: Detailed explanation of what went wrong, including what was expected versus what happened
• •Severity: Impact level — Critical (system down, data loss), High (major feature broken, no workaround), Medium (feature broken, workaround exists), Low (cosmetic, minor inconvenience)
• •Priority: Urgency of fix — P1 (fix immediately), P2 (fix this sprint), P3 (fix this release), P4 (fix when possible)
• •Status: Current state in the lifecycle (Open, In Progress, Fixed, Verified, Closed, Reopened)
• •Assignee: Developer responsible for the fix
• •Reporter: Person who found and reported the defect
• •Environment: Where it was found (OS, browser, device, build version, environment)
• •Steps to Reproduce: Exact, numbered steps to recreate the defect — the most critical field in the report
• •Actual Result: What happened when the steps were followed
• •Expected Result: What should have happened instead
• •Attachments: Screenshots, screen recordings, log files, network traces

Defect lifecycle in most organizations:

New → Triaged → Assigned → In Progress → Fixed → Ready for Retest → Verified → Closed

(with possible states: Rejected, Deferred, Reopened at various points)

The distinction between severity and priority trips up many teams. Severity is an objective measure of impact — a crash is always Critical severity. Priority is a business decision about when to fix it — a Critical crash in a feature used by 0.1% of users might be P3 (fix this release) while a Medium-severity styling issue on the pricing page might be P1 (fix immediately) because it's hurting conversions. Severity is set by the tester who finds the defect; priority is set by the product owner or triage team.

One of the most common mistakes in defect management is writing bug reports that can't be reproduced. "The app crashed" tells a developer nothing. "The app crashed when I clicked something on the checkout page" is barely better. A good bug report reads like a recipe: anyone should be able to follow the steps and see the same problem. Include the exact data used, the exact sequence of actions, and any relevant environmental details. If the defect is intermittent, say so explicitly and note how many times it reproduced out of how many attempts. Another frequent issue is defect hoarding — testers log defects but nobody triages them, leading to a backlog of hundreds of unreviewed bugs that nobody trusts or uses. Regular triage sessions (daily or per-sprint) keep the defect backlog healthy and actionable.

Defects found earlier in the software development lifecycle are dramatically cheaper to fix. A requirements defect caught during review might cost an hour to fix; the same defect found in production after release might cost weeks of emergency patching, customer communication, and reputation repair. This is why testing early and often — through requirements reviews, design reviews, and shift-left testing — is so valuable. The goal isn't to find zero defects (that's unrealistic) but to find them as early as possible and fix the highest-impact ones first.