What is the difference between bugs, defects, errors, and failures?
A person's error leaves a defect in the code, and that defect can cause a failure when the code runs. An error is a human action, a defect is a flaw in what the person made, and a failure is wrong behavior that someone observes. "Bug" is the everyday word for a defect, and "fault" is another synonym.
The International Software Testing Qualifications Board (ISTQB) Foundation syllabus states the same chain. People make errors, errors produce defects, and defects may result in failures. The chain can stop at the defect, because a defect causes a failure only when its code runs under the right conditions.
Software testing that runs the code exposes failures, and debugging works back from a failure to the defect behind it. A review that reads the code can find a defect directly, before it causes any failure.
What is an error?
The ISTQB defines an error as a human action that results in a defect, and gives "mistake" as a synonym. The action can happen at any step, e.g. writing a requirement that leaves out a case.
Programmers also use "error" for something else. A runtime error, e.g. a JavaScript TypeError, is a message or object that a program produces when an operation fails while it runs. It often comes with a stack trace, the list of function calls that were active when the program raised it. That message is a sign of a failure or of bad state, not the human action behind it.
Dependability research uses a third meaning. In a 2004 taxonomy, Avizienis and colleagues define an error as the part of a system's state that may lead to a failure. They call the cause of an error a fault, so their chain runs from fault to error to failure.
What is a defect or bug?
The ISTQB defines a defect as an imperfection or deficiency in a work product that does not meet its requirements or specifications, or that impairs its intended use. It lists bug, fault, and flaw as synonyms. Some tutorials split "bug" and "defect" by who finds the flaw, a developer or a tester. The ISTQB glossary makes no such split.
A defect in code does nothing until that code runs. The ISTQB syllabus says some defects cause a failure whenever their code runs, some only under specific conditions, and some may never cause one.
A defect can break the stated requirements or harm the intended use. Verification and validation check for each kind, in that order. When a defect breaks behavior that worked before a change, it is a regression. A defect that was there before the change is a pre-existing bug.
What is a failure?
The ISTQB defines a failure as an event in which a component or system does not meet its requirements within specified limits during its execution. Its synonym is "malfunction." A failure is the part of the chain that someone can observe.
Failures are what tests and users report. A tester or user files a failure as a bug report, often before anyone knows the defect behind it. Reports from a bug bash also start from failures that someone observed.
The link between failure and defect is loose in both directions. The ISTQB syllabus says errors and defects are not the only causes of failures, and names environmental conditions, e.g. radiation that damages firmware. A reported failure can also come from a broken test. In the other direction, a test can pass while a defect is present, which is a false pass.
When should a team use each term?
Here is an illustrative example. Acme Co. sells furniture online. A developer asks a coding agent to "Let customers edit their delivery address during checkout." After the release, each term fits one stage of the work:
- Report the failure. A customer with 2 items in the cart changes the delivery address. The address saved, but the cart emptied. The support ticket names a failure, because it records only what the customer observed.
- Reproduce the failure. The developer follows the reproduction steps in the ticket and gets the same empty cart.
- Find and fix the defect. The developer traces the failure to the address handler, which saves
{ address: newAddress }over the whole checkout record. That line is the defect, or bug, and the code fix changes it. - Name the error. In the root cause analysis afterward, the team looks for the human action behind the defect. The developer merged the agent's handler without reading how it saved the record. That is the error. The missing cart test is a contributing factor, because it let the defect reach customers. Fixing either one changes how the team works.
Keeping the words apart keeps the ticket, the code fix, and the process fix apart. This example is simplified. A real team would also rate the defect's severity and priority before it scheduled the fix.
What changes when a coding agent writes the code?
ISTQB's error is a human action, and text that a coding agent generates is not one. When an agent writes the code, the line that holds the defect comes from the agent's output. The human error moves to the steps around it, e.g. a request that left out a requirement. It can also sit in a review that accepted the change without running it.
An agent that receives an error message from a test run can edit the line that the message names. That edit can stop the message and leave the defect in place, a pattern called a symptom fix.
A practical adjustment is to hand the agent the failure and its reproduction steps, not only the error message. The team then accepts the fix when those steps pass on a fresh run, not when the error message stops.
How do bugs, defects, errors, and failures compare?
Errors, defects, and failures differ on these attributes:
| Attribute | Error | Defect or bug | Failure |
|---|---|---|---|
| What it is | A human action that leaves a flaw | A flaw in a work product | Wrong behavior during a run |
| Where it sits | In a person's work, e.g. a request | Usually in the code | In the running software |
| Who usually finds it | The team, in root cause analysis | Developers, while debugging or reviewing | Users and tests |
| ISTQB synonyms | Mistake | Bug, fault, and flaw | Malfunction |
| In the Acme example | Merging the handler without reading how it saves | A line that overwrites the checkout record | The address saved, but the cart emptied. |
In daily speech, people often say "bug" for both a defect and the failure it causes, e.g. "the checkout bug." In a report or a fix, naming which one is meant tells the reader whether to look at behavior or at code.
How is bug severity different from priority?
Severity and priority are two separate fields on a defect report. The ISTQB defines severity as the degree of impact a defect has on the development, testing, or operation of a system. Its glossary defines priority as the level of importance assigned to a task according to specific criteria.
Severity describes what the defect does, so testers and developers usually rate it from the failure. Priority says when to fix it. The person who owns the product's plans, e.g. a product owner, usually sets it in triage and weighs severity against business needs and deadlines.
The two ratings can disagree. A crash in a report that one person runs once a year has high severity and low priority. A misspelled company name on Acme's checkout page has low severity and high priority. The emptied cart is high on both.
FAQs
What is a fault in software testing?
A fault in software testing is another name for a defect, the flaw that can cause a failure, and the ISTQB lists it as a synonym. Dependability research uses fault for the cause of an error, which that field defines as the part of a system's state that may lead to a failure.
Who decides a bug's priority?
A bug's priority is usually set in triage by the person who owns the product's plans, e.g. a product owner. That person weighs the severity rating against business needs and deadlines, so a misspelled company name on the checkout page can outrank a crash in a yearly report.
Is a crash an error or a failure?
A crash is a failure in ISTQB terms, because the software stops meeting its requirements while it runs. The message the crash prints is often called an error. In the ISTQB sense, though, the error is the human action that left the defect in the code.
Can a failure happen without a defect?
A failure can happen without a defect that a person put in the code. The ISTQB syllabus names environmental conditions as another cause, e.g. radiation that damages firmware. A failure report can also be wrong, when a broken test fails on software that works.