Error, Defect, Failure and Root Cause

Why it matters

The right word decides what happens next. A failure is evidence you can show; a defect is what a developer must locate; the root cause is what the team must change to stop the next similar defect. A precise failure report, with the input, the expected result and the actual result, lets the developer find the real defect instead of chasing your guess.

The distinctions also protect your judgement. A passed test does not prove the code is right, because not every defect produces a failure. A failed test does not prove the product is wrong, because the environment, the test data or the test itself can be at fault.

From error to defect to failure

The ISTQB Foundation syllabus describes a chain: people make errors, errors produce defects, and defects may result in failures. The error happens in a person’s head or hands. The defect sits in a work product until someone removes it. The failure happens at run time, when the defective part is executed under conditions that expose it.

Defects are not only in code: a requirement that contradicts another, a test script that checks the wrong field and a build file that packages an old library are defects too. An undetected defect in an early work product often leads to more defects later: a wrong requirement leads to wrong code and to tests that agree with it.

• Error (mistake): misreading a requirement, typing > instead of >=, forgetting a case.
• Defect (fault, bug): can be found by a review, without running anything.
• Failure: can only be observed while the system runs.
• Some teams say "bug" for both the defect and the failure, and "error" for a message in a log. In reports, say which one you mean.

Defects without failures, failures without defects

The syllabus is explicit: some defects cause a failure every time the code runs, some only in specific circumstances, and some never. A defect stays latent when its code never runs, or never runs with the data that triggers it. That is why a passed test is evidence, not proof.

Errors and defects are also not the only causes of failures. The syllabus names environmental conditions, such as radiation or electromagnetic fields affecting firmware. In everyday testing the causes outside the code under test are more ordinary: a test server that is down, a third-party sandbox that times out, an expired certificate. Some still trace back to a human error elsewhere (a wrong value in a deployment configuration is a defect in that file), but the owner and the fix differ.

• Only in specific circumstances: a date calculation that breaks only on 29 February.
• Latent: a rounding defect in a currency the shop has not enabled yet.
• Masked: a defect in step 3 of checkout cannot show while another defect makes step 2 fail every time. The ISTQB glossary calls this defect masking.
• Environment: a form submission returns 503 Service Unavailable while the test environment’s e-mail service is being redeployed.

Try it: AI Error Message Analyzer

Root cause: why the error happened

A root cause is the fundamental reason a problem occurred, often a situation that led to the error. The syllabus lists typical reasons why people make errors: time pressure, the complexity of work products, processes, infrastructure or interactions, fatigue and a lack of training. Fixing a defect removes one problem; addressing its root cause can prevent similar defects or make them rarer.

Root cause analysis usually starts when a failure occurs or a defect is found, and keeps asking why until the answer is something the team can change. If three defects in one sprint show times in the wrong time zone, three fixes remove three defects. The root cause, such as having no agreed rule for storing and showing times and no test data from other time zones, keeps producing new ones until the team changes it.

False positives and false negatives

Tests can be wrong too. The ISTQB glossary calls a test result that reports a defect which does not exist a false-positive result, and one that misses a defect which is present a false-negative result. "Positive" here means "the test said there is a problem". The glossary also calls them a false-fail and a false-pass result.

• False positive: a checkout test fails because its test data uses a coupon that expired last week, which the product rightly rejects. The cost is investigation time.
• False negative: a price test passes because it checks only that a total is displayed, not that it is correct. The defect reaches users unnoticed.
• Before reporting a failure, rule out the test: rerun it, check its data, environment and expected result, and compare expected and actual output side by side. Before trusting a pass, read what the test actually checks.

Try it: Text Diff Try it: JSON Diff

Worked example: an Arabic name rejected at sign-up

Requirement R-07: "The full name field accepts Arabic and English letters and spaces, 2 to 60 characters." A tester signs up as Sara Alqahtani and the account is created. With the same name in Arabic script, the form answers "Name contains invalid characters". That is the failure.

She reports the input, the expected result and the actual result; the developer finds the defect below by debugging. When one submission during the session returned 503 Service Unavailable, she reran the test after the environment recovered and told its owner instead of filing a sign-up defect.

• Defect: the pattern accepts only Latin letters and spaces.
• Error: the developer copied it from an older English-only newsletter form without rechecking R-07.
• Root cause: the acceptance criteria and the shared test data contained English names only.
• A false negative found on the way: an API test had sent an Arabic name for weeks but checked only the status 200; the response body said invalid_name.
• After the fix: confirmation testing with both names, and Arabic examples added to the acceptance criteria and the test data.

// signup/validate.js
const NAME_PATTERN = /^[A-Za-z ]{2,60}$/;  // Latin letters and spaces only

NAME_PATTERN.test('Sara Alqahtani');  // true  -> account created
NAME_PATTERN.test('سارة القحطاني');   // false -> "Name contains invalid characters"

Try it: Regex Tester Try it: AI Bug Description Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.