Error, Defect, and Failure

Why Precision Matters #

In everyday conversation, people use “bug,” “error,” “defect,” and “failure” interchangeably. In professional testing, these terms have specific, distinct meanings. Understanding the difference is not pedantic — it determines whether you fix the symptom or the root cause.

When a customer reports “the app crashed,” they are describing a failure. When a developer finds the null pointer exception in line 42, they found the defect. When the team discovers that the developer forgot to handle the case where the database returns empty results, they identified the error.

Three different things. Three different levels of the problem. Fixing only the failure (restarting the app) or only the defect (adding a null check) without addressing the error (why are empty results not handled systematically?) guarantees the problem will recur.

Error: The Human Mistake #

An error (also called a mistake) is a human action that produces an incorrect result. Errors happen because humans are fallible — we misunderstand requirements, make typos, forget edge cases, apply wrong logic, or simply have a bad day.

Examples of Errors #

• A developer misreads the specification and implements “greater than” instead of “greater than or equal to”
• A designer uses the wrong color code (#FF0000 instead of #EE0000)
• A business analyst writes an ambiguous requirement that can be interpreted two ways
• A DevOps engineer types the wrong IP address in the deployment configuration
• A tester writes a test case with an incorrect expected result

Key Insight #

Not every error leads to a defect. A developer might make a mental error while coding but catch it immediately during a self-review. The error occurred (the wrong thought) but no defect was created (the code was corrected before commit).

Defect: The Bug in the Artifact #

A defect (also called a bug or fault) is a flaw in a work product — code, documentation, design, configuration — that may cause the system to fail. A defect is the concrete manifestation of an error in an artifact.

Examples of Defects #

• An off-by-one error in a loop: for (i = 0; i <= array.length; i++) instead of i < array.length
• A missing validation for negative numbers in a quantity field
• An incorrect SQL query that joins the wrong tables
• A typo in an error message: “Yoru password is incorrect”
• A misconfigured timeout value in a configuration file

Key Insight #

Not every defect leads to a failure. A defect might exist in code that is never executed, in a feature that is disabled by a feature flag, or in a condition that requires specific (and rare) inputs to trigger. These are called dormant defects — they exist but have not yet manifested as failures.

Failure: The Observable Problem #

A failure is a deviation of the system from its expected behavior during execution. It is what the user sees, experiences, or reports. A failure is the observable consequence of a defect being triggered.

Examples of Failures #

• The application crashes when submitting a form
• The checkout page shows $0.00 for a $99.99 product
• The search returns results in the wrong language
• The login page takes 45 seconds to load
• The password reset email is never sent

Key Insight #

Not every failure is caused by a defect in the software. Failures can also be caused by:

• Environmental issues: Server out of memory, network timeout, disk full
• External dependencies: Third-party API is down, database connection pool exhausted
• Data issues: Corrupted data in the database, unexpected data format from an integration
• Human factors: User enters data in an unexpected way

The Chain: Error → Defect → Failure #

The chain works like this:

1. A person makes an error — a developer misunderstands that dates should be stored in UTC
2. The error produces a defect — the code stores dates in local time instead of UTC
3. The defect may cause a failure — users in different time zones see wrong dates for scheduled events

But the chain can break at any link:

• An error might not produce a defect (caught in code review)
• A defect might not cause a failure (the code path is never executed)
• A failure might not be noticed (it happens in a rarely used feature)

Root Cause Analysis #

Understanding the error-defect-failure chain enables root cause analysis (RCA) — the practice of tracing a failure back through its defect to the underlying error that caused it.

The Five Whys Technique #

A simple but powerful RCA technique is asking “Why?” five times:

Failure: The monthly report shows incorrect revenue totals.

1. Why? Because the report query sums orders that were refunded.
2. Why? Because the query does not filter out refunded orders.
3. Why? Because the developer did not know that refunded orders remain in the orders table.
4. Why? Because the database schema documentation does not explain refund handling.
5. Why? Because there is no process for documenting data model decisions.

The real fix is not just updating the query (fixing the defect). It is creating documentation standards for the data model (fixing the error’s root cause) and establishing a review process (preventing similar errors).

RCA Levels #

Fixing only the symptom is firefighting. Fixing the root cause is engineering. Fixing the systemic cause is quality assurance.

Practical Classification #

Here is a complete scenario traced through all three levels:

Scenario: An e-commerce site charged a customer twice for the same order.

Failure (what happened): The customer’s credit card was charged $149.99 twice for order #12847.

Defect (the bug): The payment API call lacked idempotency — when a network timeout caused the first call to return an error, the retry sent a second payment request. The API processed both because it had no mechanism to detect duplicates.

Error (the human mistake): The developer assumed the payment API was idempotent (safe to retry). They did not read the API documentation, which explicitly states that callers must include a unique transaction ID to prevent duplicate charges.

Root cause (the process gap): No code review checklist exists for payment integrations. No integration testing verifies idempotent behavior.

Exercise: Classify Error, Defect, and Failure #

For each scenario, identify the error, defect, and failure:

Scenario 1: A user registers with the email “john@example.com” and receives a welcome email addressed to “null.”

Scenario 2: A flight booking system allows a passenger to book a seat that has already been booked by someone else.

Scenario 3: An ATM dispenses $300 when a customer requests $200.

Pro Tips #

Tip 1: Always trace to root cause. When you find a defect, do not just file the bug and move on. Ask “what error led to this defect?” and “could similar errors produce other defects?” The defect you found might be one of many caused by the same root cause.

Tip 2: Defects can exist in any artifact. Most people think of defects as bugs in code. But defects can exist in requirements documents, design specifications, test cases, configuration files, and documentation. A wrong requirement is a defect too.

Tip 3: Track the error-defect-failure chain in your bug reports. Instead of just describing the failure (“the page crashes”), describe all three levels when possible. This gives developers the context they need to fix the root cause, not just the symptom.

Key Takeaways #

• Error is a human mistake; defect is a flaw in an artifact; failure is observable incorrect behavior
• The chain flows: Error → Defect → Failure, but can break at any link
• Not all errors produce defects, and not all defects cause failures
• Root cause analysis traces failures back to their underlying errors
• Fixing symptoms (failures) without addressing root causes (errors) guarantees recurrence
• The “Five Whys” technique is a simple but powerful tool for root cause analysis