Error vs Bug vs Defect vs Failure
These four terms are often used interchangeably — but they have distinct meanings in software testing. Getting this right matters, especially in ISTQB exams and formal defect reports.
| Term | Definition | Who Introduces It | Example |
|---|---|---|---|
| Error | A human mistake made while writing code or designing the system | Developer / Designer | Developer writes if age > 18 instead of if age >= 18 |
| Bug / Defect | The flaw in the code caused by that error — found during development or testing | Present in the code | The 18-year-old user gets rejected at registration |
| Failure | When a defect is encountered by an end user in production | Visible to the end user | Customer calls support: "I can't register even though I'm 18" |
The Bug Life Cycle
The Bug Life Cycle (also called the Defect Life Cycle) defines all the states a defect passes through — from the moment it's discovered to the moment it's formally closed. Understanding this cycle is essential for QA engineers to track and manage defects effectively.
All Bug Statuses Explained
| Status | Who Sets It | What It Means |
|---|---|---|
| New | Tester | Defect is raised for the first time and logged in the defect tracking system |
| Assigned | Test Lead / Manager | Bug is approved as valid and assigned to the development team for fixing |
| Open | Developer | Developer has started analysing the defect and is working on a fix |
| Fixed | Developer | Developer has made the code change and believes the issue is resolved |
| Pending Retest | Developer | Fix is ready but awaiting the tester to pick it up — tester hasn't started yet |
| Retest | Tester | Tester is actively retesting the fix in the current build |
| Verified | Tester | Tester confirms the fix works — defect no longer reproducible |
| Reopened | Tester | Bug still exists after the supposed fix — sent back to developer |
| Closed | Tester / QA Lead | Defect is fully resolved, verified, and formally closed in the system |
4 Special Conditions (Not the Normal Path)
Not every defect follows the standard path. These four statuses represent special outcomes:
| Condition | Who Sets It | When Applied |
|---|---|---|
| Duplicate | Developer / QA Lead | The same defect has already been reported by another tester — close as duplicate of the original |
| Rejected | Developer | Developer disputes the defect — it's working as designed, or the tester misunderstood the requirement |
| Deferred | Project Manager / Product Owner | The bug is valid but not priority enough for this release — will be fixed in a future version |
| Not a Bug | Developer / Business Analyst | The reported behaviour is actually correct — no defect exists |
Severity vs Priority
These two properties of a defect are often confused but are fundamentally different dimensions:
- Severity measures the technical impact of the bug on the application — how much it breaks.
- Priority measures the business urgency of fixing the bug — how soon it needs to be fixed.
Severity Levels
| Level | Definition | Example |
|---|---|---|
| Blocker | Testing cannot proceed — the defect blocks the entire test cycle | App crashes immediately on launch |
| Critical | Core functionality is completely broken | Payment fails for all users |
| Major | A supporting component doesn't work, but core features still function | Email notifications not sent after order |
| Minor | UI or cosmetic issue — testing can proceed without interruption | Button label has a typo; wrong colour on a non-critical element |
Priority Levels
| Level | Definition | Example |
|---|---|---|
| High | Fix immediately — affecting users right now in production | Login is broken for all users |
| Medium | Fix before the current release ships | A reporting filter returns wrong data |
| Low | Fix if time allows; can be deferred to next release | Footer text has a spelling error |
Severity-Priority Matrix — Real-World Combinations
High Priority
Payment crash on launch
Low Priority
Critical bug in rarely used module
High Priority
Company logo broken on homepage
Low Priority
Typo in about page footer
Defect Report Format
A well-written defect report is the single most important communication between a tester and a developer. Missing information leads to delays and "cannot reproduce" responses. Here's the standard format:
| Field | Description | Example |
|---|---|---|
| Defect ID | Unique identifier (auto-generated in tools like JIRA) | BUG-1042 |
| Project / Module | Which project and module is affected | E-Commerce / Checkout |
| Defect Title | Short, clear, specific description of the issue | "Payment fails with valid Visa card when 3DS is enabled" |
| Severity | Technical impact (Blocker / Critical / Major / Minor) | Critical |
| Priority | Business urgency (High / Medium / Low) | High |
| Status | Current stage in the defect lifecycle | New |
| Environment | Build version, OS, browser, device | v2.3.1 / Android 13 / Chrome 120 / Pixel 7 |
| Steps to Reproduce | Numbered steps a developer can follow exactly | 1. Log in → 2. Add item to cart → 3. Enter card details → 4. Click Pay |
| Expected Result | What should happen per the requirement | Payment processes successfully, order confirmation shown |
| Actual Result | What actually happened | "Payment failed" error displayed, order not created |
| Attachments | Screenshot, screen recording, log file | screenshot.png, logcat_20260423.txt |
| Detected By / Date | Tester name and date found | Honnesh Muppala / 23 Apr 2026 |
Categories of Defects
| Category | Meaning | Example |
|---|---|---|
| Wrong | Requirement was implemented incorrectly | Discount applied as 20% but requirement says 10% |
| Missing | A customer requirement was not implemented at all | Password reset feature not built |
| Extra | A feature was added that wasn't in the requirements | A new filter field that was never requested appears on the search page |
Latent vs Masked Defects
| Type | Definition | Example |
|---|---|---|
| Latent Defect | An existing defect that hasn't caused a failure yet — because the exact conditions to trigger it haven't occurred | A divide-by-zero bug exists in code but never triggers because no one has ever searched with zero results |
| Masked Defect | A defect that is hidden by another defect — only revealed once the covering defect is fixed | Bug A prevents the login module from reaching a broken payment screen. Fix Bug A, and Bug B (the payment screen crash) suddenly appears |
The 7 Testing Principles
These principles, defined by the ISTQB, are the philosophical foundation of software testing. Every QA engineer should know them:
| # | Principle | What It Means |
|---|---|---|
| 1 | Testing shows the presence of defects | Testing can prove bugs exist but cannot prove a system is bug-free |
| 2 | Exhaustive testing is not possible | You cannot test every input combination — use risk-based approaches and design techniques instead |
| 3 | Early testing | Find defects as early as possible — fixing in requirements costs 100× less than fixing in production |
| 4 | Defect clustering | Most defects are concentrated in a small number of modules (the Pareto principle: 80% of bugs in 20% of code) |
| 5 | Pesticide paradox | Running the same tests repeatedly finds fewer new defects — refresh your test suite regularly |
| 6 | Testing is context dependent | Testing a banking app requires different rigor than testing a games app — adapt your approach |
| 7 | Absence of error fallacy | A bug-free system that doesn't meet user needs is still a failure — quality includes fitness for purpose |
Bug Metrics and Quality KPIs
Logging and closing bugs is only part of defect management. The most mature QA teams track quantitative metrics that reveal the health of the testing process itself — and surface systemic problems before they become release blockers. Here are the five metrics every QA engineer and test manager should understand.
Defect Density
Defect Density measures the number of confirmed defects relative to the size of the software under test. It is typically expressed as bugs per KLOC (thousand lines of code) or bugs per feature. A new web module with 5,000 lines of code and 15 logged defects has a defect density of 3 per KLOC.
What is a healthy number? It depends heavily on domain and technology — embedded systems typically run higher than web apps — but a range of 1–5 defects per KLOC is commonly considered acceptable during active development. Above 10 is a signal that either code quality is poor or requirements were unclear at the outset.
Defect Leakage Rate
Defect Leakage Rate (DLR) measures what percentage of total bugs were only discovered in production — after the product shipped — rather than during QA. The formula is:
DLR = (Defects found in production ÷ Total defects found) × 100
A leakage rate above 10% is a warning sign. Above 20% suggests the regression strategy has significant gaps. Teams with strong automation coverage and mandatory exploratory cycles routinely achieve leakage rates below 5%.
Mean Time To Detect (MTTD) and Mean Time To Resolve (MTTR)
MTTD measures the average time between when a defect is introduced into the codebase and when it is first reported. Shorter MTTD means testing is finding bugs quickly after code changes — a sign of healthy shift-left practices and frequent build cycles. MTTR measures the average time from bug report to confirmed fix and closure. High MTTR can indicate developer capacity problems, unclear defect reports, or an inefficient retest workflow. Both metrics should be tracked per severity — a Critical bug with an MTTR of five days is a process failure; a Minor cosmetic bug with the same MTTR is acceptable.
Bug Age
Bug Age tracks how long a defect has been open without resolution. Aging bugs — particularly those in New or Assigned status for more than two sprints — are a management red flag. They indicate either that the bug is disputed (should be formally deferred or closed as Not a Bug), that developer capacity is misallocated, or that the priority was set incorrectly. A regular bug-aging review in sprint planning prevents open defect lists from growing silently into technical debt.
Escaped Defect Rate
Escaped Defect Rate is arguably the most critical metric for release readiness. It counts the number of defects that escaped to production in a given release cycle. Unlike DLR (which is a ratio), escaped defect rate is an absolute count and is directly visible to end users. For organisations dependent on AdSense or user-retention metrics, even a single escaped Critical defect can affect monetisation. Most release checklists gate go/no-go decisions on this number — zero escaped Critical or High bugs is a standard pre-release requirement.
Quick Reference — Bug Metrics at a Glance
| Metric | Formula | Target | Warning Sign |
|---|---|---|---|
| Defect Density | Bugs ÷ KLOC | < 5 per KLOC | > 10 per KLOC |
| Defect Leakage Rate | (Prod bugs ÷ Total bugs) × 100 | < 5% | > 15% |
| MTTD | Avg time: introduced → reported | Same sprint as change | Bugs found 2+ sprints later |
| MTTR | Avg time: reported → closed | < 3 days for Critical | > 5 days for Critical |
| Bug Age | Days open since creation | Reviewed every sprint | Open > 2 sprints with no action |
| Escaped Defect Rate | Count of bugs found in production per release | 0 Critical/High | Any Critical in production |
References
- ISTQB Foundation Level Syllabus — Chapter 1: Fundamentals of Testing
- IEEE 1044 — Standard Classification for Software Anomalies
- Kaner, C. — Lessons Learned in Software Testing, Wiley
- JIRA Bug Tracking Best Practices — Atlassian Documentation
Back to Blog