Defect vs Failure vs Error vs Mistake: The ISTQB Distinctions Candidates Get Wrong

This is one of the most commonly tested concepts on the ISTQB Certified Tester Foundation Level exam and one of the most commonly failed. Almost every CTFL candidate reads the four-term definition once, thinks they understand it, and then loses a mark on exam day because they cannot apply it to a scenario they have not seen before.

These four terms are also among the most misused in everyday testing conversation. Developers, managers, and testers routinely say “bug” and “defect” and “error” interchangeably in standups. In casual work that is fine. On the CTFL exam it will cost you.

This article walks through each term, the hierarchy that links them, five exam-style questions with full explanations, and a memory aid that sticks.

If you are preparing for the exam as a whole, start with the CTFL v4.0 syllabus deep dive. If you are worried about failure patterns, read 7 Reasons Candidates Fail the ISTQB CTFL Exam.

The Four Terms in One Sentence

Here is the shortest useful summary you will get:

A human mistake causes a defect in the work product, which may cause a failure when the software runs. The mental slip itself is the error.

That single sentence encodes the hierarchy and the causal relationship. Everything else in this article elaborates on it.

The Four Definitions

Let’s take each term in the correct order, from cause to observable effect.

Mistake (sometimes called “human error”)

A mistake is a human action that produces an incorrect result. It happens in someone’s head or hands. A developer intends to type > but types >=. A requirements author intends to specify 18 as the minimum age but writes 16. A tester intends to execute test case 47 but runs test case 74.

The mistake is the human action. It is not the code, not the document, not the observable system behaviour. It is the thing a person did (or thought or typed) that was not what they intended.

Error

In most ISTQB contexts, error is used as a synonym for mistake, meaning the human action that produces a wrong result. Some older materials and some individual questions treat “error” as the mental state (the confused understanding) that led to the mistake, with “mistake” being the physical action.

For exam purposes, treat mistake and error as interchangeable unless a specific question forces a distinction. The v4.0 syllabus does not make a sharp distinction between them in the way it does between defect and failure.

If a question does force a distinction, the convention is:

• Error: the human being confused, distracted, or misinformed (mental cause)
• Mistake: the resulting incorrect action (physical or verbal manifestation)

In practice, on the exam you are far more likely to see error used loosely to mean “the human cause,” with the important distinctions being between error/mistake (human), defect (work product), and failure (observable behaviour).

Defect (also called “bug,” “fault,” or “problem”)

A defect is a flaw in a work product that can cause a failure when the product is executed. The operative word is flaw: the defect is the thing that is wrong, not the thing the human did to cause it and not the thing the user eventually sees.

Defects live in work products. A work product is anything produced during development: code, requirements documents, design diagrams, test cases, user stories. A typo in the code is a defect. An ambiguous requirement is a defect. A missing test case is a defect.

Crucially, defects can exist without anyone knowing they exist. A defect is in the code whether or not the code has been executed. If code containing a defect is never executed along the faulty path, the defect is still there; it has simply not produced a failure yet.

Failure

A failure is an observable deviation between the actual behaviour of the system and its expected behaviour. The operative word is observable. A failure is what a user, a tester, or a monitoring tool sees: the wrong total on the invoice, the crashed screen, the missing button, the incorrect result.

A failure cannot exist without execution. If the code is not run, there is no failure, even if the defect causing a potential failure is present. This is why testing is sometimes defined as “triggering failures to reveal defects.”

Failures are also not always caused by defects in the software. Environmental conditions (network outages, hardware faults, power failures) can produce behaviour that looks like a failure but has no corresponding software defect.

The Hierarchy Visualised

Here is the chain, with an example:

Step	Term	What it is	Example
1	Mistake / Error	Human action (or confusion) that produces a wrong result	The developer intends to use > but types >=
2	Defect	Flaw in the work product (the code, the document)	The line of code now reads if age >= 18 when the requirement said “older than 18”
3	Failure	Observable incorrect behaviour when the product runs	When a user enters age 18, they are allowed access even though they should not be

Not every mistake produces a defect (sometimes the human catches the mistake before it enters the work product). Not every defect produces a failure (the faulty code path may never execute). Not every failure is caused by a defect (environmental issues can trigger failures too).

These three “not always” conditions are frequently tested.

Why the Exam Cares So Much About This

The exam tests this distinction because it underpins how testers think about their work.

• Testers find failures. When we run tests, we observe behaviour and compare it to expected results. What we actually detect is failures.
• Testers then identify defects. From the failure, we investigate and locate the defect in the work product that caused it. This is an investigation step, not a testing step in the pure sense.
• Defects are fixed by addressing the human cause. Someone traces the defect back to the mistake that introduced it, often to improve the development process.

If a tester cannot distinguish these three layers, they cannot reason clearly about what testing does and does not achieve. The exam is protecting a mental model, not just vocabulary.

The Official ISTQB Framing

The v4.0 syllabus uses these definitions consistently with the ISO/IEC/IEEE 29119 family of standards:

• A person makes a mistake (error)
• This produces a defect (fault) in the work product
• Executing the work product produces a failure

In older ISTQB materials, you will see the term fault used as a synonym for defect. On the v4.0 exam, defect is the preferred term, but a question could use either. Treat them as equivalent.

The Most Common Misunderstandings

Here are the errors (in the common-English sense) that candidates make.

Misunderstanding 1: Treating defect and failure as the same thing

This is by far the most common error. Candidates say “the test found a defect” when what they actually mean is “the test observed a failure, from which a defect was inferred.”

The test sees output; it does not see code. The code is the defect; the output is the failure.

Misunderstanding 2: Calling the human action a “bug”

In everyday speech, a “bug” is whatever is wrong. In ISTQB terminology, “bug” is a synonym for defect, not for mistake or failure. Candidates who think of bugs as the observable problem confuse themselves when the exam asks about failures.

Misunderstanding 3: Thinking every defect produces a failure

A defect in code that is never executed does not produce a failure. This is why test coverage matters and why the ISTQB principle “exhaustive testing is impossible” has real practical implications: defects can hide in untested code paths indefinitely.

Misunderstanding 4: Thinking every failure is caused by a defect

Failures can be caused by environmental conditions (power outage, corrupted file, network timeout) with no software defect involved. When the exam presents a scenario, read carefully to see whether the failure has an identifiable defect behind it.

Misunderstanding 5: Confusing root cause with defect

The root cause of a defect is usually the human mistake (or sometimes a process weakness, a communication breakdown, or missing knowledge). The defect is the thing in the work product. The root cause is why the defect got there. Do not conflate them.

Five Exam-Style Questions

Work through these before reading the answers. Cover the explanations until you have picked your option.

Question 1

A developer misreads a requirement that says “users aged 18 or older may register.” The developer writes if (age > 18) registerUser(). During testing, a tester enters age 18 and observes that the system rejects the registration.

Which of the following correctly identifies what happened?

A) The misreading was a defect, and the rejection was a failure B) The misreading was a mistake, the incorrect code was a defect, and the rejection was a failure C) The misreading was a failure, and the incorrect code was a defect D) The misreading was a mistake, and the rejection was a defect

---

Question 2

A banking application contains a line of code that would produce an incorrect interest calculation if triggered. This code path is only executed when the account balance exceeds 10 million USD. No customer has ever held such a balance.

Which of the following statements is TRUE?

A) There is no defect in the software because no failure has occurred B) There is a defect in the software, but no failure has occurred C) There is both a defect and a failure, but the failure is latent D) There is a failure in the software, but no defect

---

Question 3

A user reports that a web application froze and displayed an error message. Investigation reveals that the freeze occurred because the user’s internet connection dropped for 30 seconds. The application code contains no flaw; it simply timed out.

Which of the following best describes this situation?

A) A defect caused a failure B) A failure occurred, but it was not caused by a defect in the software C) A mistake was made by the user D) No failure occurred because the software behaved correctly

---

Question 4

Which of the following best describes the relationship between a defect and a failure?

A) Every defect always causes a failure B) Every failure is always caused by a defect C) A defect may cause a failure when the defective code is executed D) A failure is a defect that has been reported

---

Question 5

Which of the following is NOT a valid example of a defect?

A) A typographical error in a requirements document that makes the requirement ambiguous B) A missing semicolon in source code that prevents compilation C) A tester entering the wrong test input during execution D) An incorrect calculation in a design document

---

Answers and Explanations

Question 1: B

The chain is mistake (the misreading) → defect (the incorrect code age > 18 instead of age >= 18) → failure (the observable rejection of a valid age-18 user). Option B is the only one that captures all three layers correctly.

Option A collapses the mistake and the defect into one term. Option C labels the misreading as a failure, which is incorrect because a failure is observable system behaviour, not a human cognitive event. Option D labels the failure as a defect, which reverses the hierarchy.

Question 2: B

A defect exists in the code because the code is flawed: it would produce an incorrect result under certain conditions. The defect is there regardless of whether it has been triggered.

However, no failure has occurred, because no execution has ever taken the faulty path. Failures are observable; unobserved potential failures are not failures.

Option A is wrong because defects exist independently of whether they have produced failures. Option C is wrong because a “latent failure” is not standard ISTQB terminology; a failure is observable by definition. Option D reverses defect and failure.

This question tests the principle that defects can exist without producing failures, which is why exhaustive testing is impossible and why risk-based testing matters.

Question 3: B

A failure is observable incorrect behaviour. The freeze and error message are observable. So a failure has occurred.

But the cause was environmental (the network drop), not a flaw in the software. Therefore there is no defect in the software to fix.

Option A is wrong because there is no defect. Option C is a distractor: the user did not make a mistake, their connection dropped. Option D is wrong because the user observed incorrect behaviour, which meets the definition of a failure regardless of cause.

This question tests the principle that failures can be caused by factors other than software defects. It is a commonly misread question because candidates default to assuming every failure has a defect behind it.

Question 4: C

Option C is the only one that accurately captures the relationship: a defect may cause a failure, but only when the defective code is executed.

Option A is too strong: defects can exist without producing failures (as seen in Question 2). Option B is too strong: failures can occur without defects (as seen in Question 3). Option D misdefines failure as a reported defect, which conflates two distinct concepts.

Question 5: C

A defect is a flaw in a work product. Source code, requirements documents, and design documents are all work products. Typos, missing semicolons, and incorrect calculations in these are all defects.

Option C describes a tester making a mistake during test execution. That is a human mistake, not a defect in the work product. If the tester’s wrong input causes the test to produce an incorrect result, that is an invalid test, not a defect in the software.

This question tests whether you can distinguish the definition of a work product from the broader testing process. Human mistakes during testing do not produce defects in the software being tested.

---

A Worked Real-World Example

Let’s apply the full four-term chain to a realistic scenario, so you can see how it works.

Scenario: A flight booking system should block bookings when fewer than two seats remain on the flight, to reserve capacity for premium customers. A developer implements this rule.

The mistake (error)

The product manager tells the developer: “block bookings when there are fewer than two seats left.” The developer types the condition. But the developer is distracted during a standup and later remembers the rule as “block bookings when there are two or fewer seats left.” This misremembering is the mistake.

The defect

The developer writes:

if (seatsRemaining <= 2) blockBooking();

The correct code should have been:

if (seatsRemaining < 2) blockBooking();

The code in the repository is now flawed. This is the defect. It sits there waiting to be triggered.

The failure (version 1)

A customer tries to book a flight that has exactly 2 seats remaining. The system blocks the booking. The customer calls support to complain. This is an observable deviation from expected behaviour. This is a failure.

An alternative: the defect that does not produce a failure

If the flight is never in a state of having exactly 2 seats remaining (for example, because most flights in this airline only sell in bulk blocks of 5 or more seats), the defect is still present but no failure ever occurs. The defect is latent until the conditions that trigger it are met.

An alternative: the failure that is not caused by this defect

On the same system, a customer reports that they could not book because the payment gateway timed out. The payment gateway is operated by a third party and is experiencing an outage. A failure has occurred (the customer observed the system failing to complete their booking), but the cause is not this defect, not any defect in the booking system. It is an environmental factor.

That is the full four-term chain, with the edge cases that make the concept worth testing.

A Memory Aid

If you need to hold this in memory under exam pressure, use the “MDF chain”:

• Mistake: a human did something wrong
• Defect: it left a flaw in the work product
• Failure: the flaw became observable when the product ran

Read the question stem and ask: which of these three layers is the question pointing at?

• If the question describes something a person did (typed, wrote, thought, misread), that is the mistake layer.
• If the question describes something in a document or in code, that is the defect layer.
• If the question describes something a user, tester, or system observed as wrong, that is the failure layer.

Classify the clues in the question, then match them to the correct answer.

Related Terms Worth Knowing

The exam sometimes surrounds defect/failure questions with adjacent vocabulary. Know these too:

• Root cause: the underlying reason a defect was introduced. Usually a process, knowledge, or communication weakness.
• Fault: synonym for defect. Older ISTQB materials and some standards prefer fault.
• Anomaly: any condition that deviates from expectation. Broader than defect or failure. An anomaly could turn out to be either, or neither (perhaps the expectation itself was wrong).
• Issue: informal term, usually meaning an unverified anomaly that has been reported and needs investigation.
• Incident: an event that requires investigation, often used in production-support contexts.

On the exam, if a question uses “fault” rather than “defect,” treat them as equivalent. If a question uses “anomaly” or “incident,” these are less specific terms and the question will usually clarify whether you should treat them as a failure or a defect based on context.

Where This Appears in the Syllabus

The defect-failure-error-mistake distinction appears primarily in Chapter 1 (Fundamentals of Testing) of the CTFL v4.0 syllabus, but it resurfaces in:

• Chapter 2 (Testing Throughout the SDLC): when discussing early testing and defect prevention
• Chapter 3 (Static Testing): when discussing how reviews find defects before they can cause failures
• Chapter 5 (Managing the Test Activities): in the defect management and defect report sections

Expect at least one direct question on this distinction, plus one or two indirect questions where the vocabulary must be used correctly to interpret the scenario.

Quick Self-Check Before the Exam

Before you book the exam, make sure you can do all of these without notes:

1. Define each of the four terms in one sentence.
2. Explain the causal chain from mistake to failure.
3. Give an example of a defect that has not produced a failure.
4. Give an example of a failure not caused by a defect.
5. Identify each of the three layers in a short scenario, such as the flight booking example above.

If any of these is shaky, re-read this article and work through the five practice questions again.

Next Steps

This is just one of many term-pair distinctions the CTFL exam tests. Others to study carefully include: verification vs validation, confirmation testing vs regression testing, test monitoring vs test control, severity vs priority, and product risk vs project risk. Our 7 Reasons Candidates Fail the ISTQB CTFL Exam post covers the full set of commonly confused pairs.

For structured preparation across the whole syllabus, our CTFL v4.0 Study Guide includes a full confusion table of term pairs, hundreds of practice questions, and worked examples for every Chapter 4 technique.