One of the fastest ways to spot a junior tester is to listen to how they use the word "bug." In conversation, "bug" is fine — everyone knows what you mean. But in professional communication, in a bug report, in a post-mortem, in a client presentation — precision matters.
ISTQB (the International Software Testing Qualifications Board, which sets global testing standards) defines three distinct terms that describe the same problem at different stages of its existence.
Learning Objectives
By the end of this lesson you will be able to:
- Define Error, Defect, and Failure using ISTQB terminology
- Trace the chain from human mistake to user-visible malfunction
- Apply these definitions correctly in professional communication
The Three-Link Chain
Link 1: Error (also called Mistake)
An Error is a human action that produces an incorrect result. It happens in someone's mind — a developer, analyst, architect — before it reaches the code.
Examples:
- A developer misunderstands a requirement and implements the wrong business logic
- A BA writes an ambiguous requirement that can be interpreted two ways
- An architect specifies the wrong data type for a field
The error itself is invisible at this stage. Nothing has gone wrong in the product yet — it's all in someone's head (or their misreading of a document).
Link 2: Defect (also called Bug or Fault)
A Defect is an imperfection in a work product that causes it to fail to meet requirements. It's the concrete manifestation of an error in a deliverable — code, a requirements document, a test case, or any other artifact.
Examples:
- The wrong business logic written as code (the error from above is now in the codebase)
- An if-condition that should use
>=but uses>instead - A null pointer reference that only triggers under specific conditions
The defect is present in the artifact. It may or may not cause a visible problem yet — it's a latent bomb waiting for the right conditions to detonate.
Link 3: Failure
A Failure is the deviation of a component or system from expected behavior. It's what the end user actually experiences. It's the bomb going off.
Examples:
- The user clicks Submit and sees a 500 error page instead of a confirmation
- The total in the shopping cart is incorrect because of the wrong business logic
- The application crashes when a user uploads a file larger than 10 MB
The Chain in a Single Example
Error: A developer misreads the requirements and assumes the minimum password length is 6 characters instead of 8.
Defect: The validation code in RegistrationService.java checks password.length() >= 6 instead of >= 8.
Failure: A user registers with a 7-character password. The app accepts it. When the user tries to log in on a different device that has stricter client-side validation, they cannot authenticate.
Notice that the defect was present the moment the code was written, but the failure only surfaced when a specific user hit the specific condition. This is why some bugs lie dormant for months before they're discovered.
Why This Terminology Matters
When you write "The developer made an error," you're describing intent. When you write "The system produced a failure," you're describing observable behavior — which is what a bug report should do.
Using precise terms also helps in root cause analysis. When a failure is found, working backwards through Failure → Defect → Error helps the team understand where the problem was introduced and when it could have been caught.
Pro Tips
In bug reports, describe Failures. Write what the system did (or didn't do), not what the developer intended or what caused it. Reserve Error and Defect analysis for post-mortems and root cause discussions.
Not all defects become failures. A defect in a code path that is never executed will never produce a failure. This is why code coverage alone doesn't guarantee quality.
Summary
- An Error is a human mistake that introduces a problem.
- A Defect is the concrete manifestation of that mistake in an artifact (usually code).
- A Failure is the observable deviation from expected behavior that an end user experiences.
- The chain goes: Error → Defect → Failure.
- Bug reports should describe Failures; root cause analysis explores Errors.