Bug vs Defect vs Error vs Failure: What the Difference Actually Is (2026)
Your tracker has a Type field with "Bug" and "Defect" in the dropdown, and you have just opened a ticket. Which one do you pick? One colleague says they are the same thing. Another says a bug is the narrower one. The test report you are writing also says "failure," and you are not sure whether that is a third synonym or something further down the chain.
In ISTQB terminology, bug and defect are synonyms. The distinctions that matter sit between error, defect, and failure: a human makes an error, the error produces a defect in a work product, and the defect may show up as a failure when the software runs. The one word that breaks consistency across sources is "fault," and most of this article is about why.
The short answer
Bug and defect mean the same thing in ISTQB terminology. The ISTQB TBOK, which carries the CTFL v4.0.1 text, puts it this way: "Human beings make errors (mistakes), which produce defects (faults, bugs), which in turn may result in failures."
An error is a human mistake, a defect is the imperfection it leaves in a work product, and a failure is wrong behaviour observed while the software runs.
"Fault" is the word that changes meaning between sources. ISTQB groups it with defect, Amy J. Ko's teaching text makes it a program state, and dependability research makes it the cause of an error. Pick the framework your document follows and use its words throughout.
Outside ISTQB, some vendors do split bug from defect. Qameta's 2023 article says "all bugs are defects, but not all defects are bugs." That is one vendor's usage, not a standard, and it is the reason you should name your framework.
Get the Mobile Testing Playbook Used by 800+ QA Teams
Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.
Bug vs defect vs error vs failure at a glance
The table uses ISTQB terminology unless a row says otherwise.
Term | What it names | Position in the chain | What you can observe |
Error | A human mistake made while building the software | Starts the chain | Not directly; you infer it from the defect it left |
Defect | "An imperfection or deficiency in a work product where it does not meet its requirements or specifications or impairs its intended use" | Produced by an error; sits in the work product, often code | Only when found by review, or when execution exposes it |
Bug | A synonym for defect in ISTQB terminology | Same position as defect | Same as defect |
Failure | Behaviour observed while the software runs that departs from what was expected | Ends the chain, but not every defect reaches it | A user, tester, or monitor sees it |
Fault | Grouped with defect by ISTQB; a program state in Ko's model; the cause of an error in dependability research | Depends on the framework | Depends on the framework |
Why the definitions don't line up
Most confusion about these words is not careless writing. Credible sources place "fault" in different slots.
ISTQB puts fault beside defect. The chain quoted above lists "defects (faults, bugs)" as one link. In ISTQB's vocabulary, fault is a synonym and needs no separate meaning.
Ko makes fault a state. In her University of Washington chapter on debugging, Amy J. Ko writes: "A fault is a program state caused by a defect that may result in a program behavior inconsistent with a program's requirements." The defect is the code. The fault is the state the running program is in afterwards, which is later in the chain than ISTQB puts it.
Dependability research makes fault the cause. SpecStory's explainer summarises the dependability model from Avizienis and colleagues' 2004 paper: the fault is the cause of an error, and the error is the part of system state that may lead to a failure. This is SpecStory's account of that paper, not a reading of the paper itself.
Zeller avoids the word. In a 2009 summary by Nicholas Nethercote of Andreas Zeller's book Why Programs Fail, the erroneous program state is called an infection, and a defect is "an erroneous piece of code." This is a secondary summary and a 2009 position, so treat it as history.
These models disagree about one layer, not about whether the layer exists. Ko's state-fault and Zeller's infection are close cousins. The sharp conflict is ISTQB against Ko on what "fault" means.
Suppose a ticket says "fault in the checkout module." Under ISTQB, a defect has been found in checkout code. Under Ko, the checkout program is in a bad state. Under dependability terms, something upstream caused an error. Each reading sends the investigation somewhere different.
The instability is also old. Widder and Le Goues, in a 2024 arXiv preprint on the word "bug", note that the Oxford English Dictionary records "bug" as a colloquialism for an engineering defect since at least the 1870s, and argue that fairly straightforward definitions "start to break down" when interrogated. A linguistics study of the same terms, Krawiec's 2018 paper in , compares mistake, error, bug, defect, fault, and failure across dictionaries and IT sources, motivated by the difficulty they cause non-native speakers.
Error vs defect: where the human sits in ISTQB's chain
ISTQB places a person at the start of the chain. An error is a mistake made while working on the software: a requirement misread, a condition written wrong, a value put in the wrong place.
A small example. The rule is "accept users aged 18 and over." The developer writes if (age > 18). The developer's mistake is the error. The wrong comparison sitting in the code is the defect. Nothing has gone wrong for any user yet. The failure appears only when someone enters exactly 18 and is turned away.
Two cautions. First, "error" has other meanings outside ISTQB. In runtime programming it often means the message or object a program produces when an operation fails; SpecStory's example is a JavaScript TypeError. If your team says "we got an error" about a crash dialog, that is the runtime sense, not the human mistake. Second, Splunk also uses the human sense, describing an error as occurring "when a human makes a mistake while coding the program", and then divides the rest of the vocabulary differently, as covered below.
Defect vs failure: the gap where most arguments happen
A defect can exist without ever producing a failure. Kochan and Wood, in their 2016 book excerpt , put it plainly: "A defect in code that's never executed won't cause a failure."
ISTQB adds gradation: "Some defects will always result in a failure if executed, while others will only result in a failure in specific circumstances, and some may never result in a failure." Ko says the same from the other direction: many defects are never executed, or never executed with inputs that make the program misbehave.
So a defect is a property of the work product, and a failure is an event at runtime. This is why a defect count and a failure count are different numbers, and why a tracker that mixes them misleads its readers. For the mechanism behind defects that sit dormant, see Quash's post on latent versus active defects.
Failures can also have causes other than the defect you expected. ISTQB states that "errors and defects are not the only cause of failures" and gives environmental conditions as an example. Its example is radiation or electromagnetic fields causing defects in firmware, so the environment still ends in a defect. Kochan and Wood list environmental conditions and incorrect or unintended use as failure causes too. The safe reading: environment and misuse can produce failures. It does not follow that those failures have no defect behind them.
What this looks like on a mobile app
Mobile makes the distinction practical because the conditions under which a defect activates vary so much. Permission state, a backgrounded process, a network that drops mid-request, or a particular OS version can decide whether a defect ever fires. That is ISTQB's "only in specific circumstances" and Ko's "never executed with inputs that cause a program to misbehave." The defect is present either way. The failure appears when conditions match.
Here is a hypothetical sequence, shown only to illustrate investigation order, not how often this happens. A tester on a mid-range Android phone reports that a payment screen goes blank after the app returns from a bank's login page. That is an observed failure, and the report says so. It records the steps, device, OS version, and network state, and it states that the cause is unknown. Later a developer finds a view released when the activity pauses and referenced on resume. Now the defect is confirmed, and the error was a lifecycle assumption made while writing that screen.
The failure was recorded first, with its conditions and an honest "cause unknown." The defect and error were named only after investigation. A ticket that opens as "defect: blank screen" skips the step where you learn what is actually behind the blank screen. Quash's free bug report template has Steps to Reproduce, Expected Result, Actual Result, and Environment fields that fit this order. Quash (our product) also generates and runs mobile test cases, so run results will show observed failures before anyone knows the defect behind them.
Which word to use where
The table below is editorial guidance reasoned from the sources above, not a standard's ruling.
Situation | Use | Why |
A document governed by ISTQB or a CTFL-based process | Defect, with bug and fault as accepted synonyms | ISTQB groups "defects (faults, bugs)" as one link |
A document using academic or dependability vocabulary | Keep defect (code) and failure (observed) strictly apart; define fault locally or avoid it | Ko treats fault as a state, dependability research as a cause; neither matches ISTQB |
A ticket title, standup, or chat message | Bug | It is the everyday word, and it has meant an engineering defect since the 1870s |
Describing what a user or tester saw | Failure (or incident, if your tracker uses that word), with the cause marked unknown | Observed behaviour is a failure before anyone knows the code behind it |
Breakage that appears to come from the environment | Record the observation and the conditions; do not write "no defect" | ISTQB's own environmental example still ends in a defect |
Do not mix frameworks inside one artefact. A test plan that says "defect" in one paragraph and "fault" in the next, with a different meaning each time, forces your reader to guess which model you had in mind. Choose one framework per document and define whatever it leaves open.
Vendor vocabularies show the drift. Splunk treats a bug as a flaw in code, a defect as a deviation from requirements, and an incident as an event affecting availability, swapping "incident" in for "failure." That is a coherent vocabulary, but it is not ISTQB's. If you adopt one, say so in your own documents.
The interview answer
If you are asked to walk through error, defect, and failure, give the chain and name it as ISTQB's: a human makes an error, the error produces a defect in the work product, and the defect may result in a failure when the software runs, though not every defect ever does.
Then add the sentence that shows you know the terrain: "Some frameworks put fault in a different place, so I would confirm which vocabulary the team uses." Popular tutorial tables, such as the GeeksforGeeks five-term comparison, present one version of the chain as settled. Your answer is stronger when it names its framework.
Conclusion
The deciding variable is the document you are writing and the framework that governs it. If it follows ISTQB, write defect and treat bug and fault as synonyms. If it follows academic or dependability vocabulary, keep defect and failure apart and define fault before you use it. A ticket title can say bug, provided the report underneath says what was observed and what is still unknown.
Before you write the first line of your next report, decide which framework it follows. Then keep to it.
Continue reading
More articles from the Quash editorial desk.
