What is the difference between a defect and a bug?
A bug is the result of a coding error
A defect is a deviation from the requirements
That is: A defect does not necessarily mean there is a bug in the code, it could be a function that was not implemented but defined in the requirements of the software.
From the Wikipedia page on software testing:
Not all software defects are caused by coding errors. One common source of expensive defects is caused by requirement gaps, e.g., unrecognized requirements, that result in errors of omission by the program designer. A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security.
Quoting Ilene Burnstein from the book Practical Software Testing (recommended) who parts from the definition in the "IEEE Standards Collection for Software Engineering" (1994) and "IEEE Standard Glossary of Software Engineering Terminology" (standard 610.12, 1990):
An error is a mistake, misconception, or misunderstanding on the part of a software developer
In the category of developer we include software engineers, programmers, analysts, and testers. For example, a developer may misunderstand a design notation, or a programmer might type a variable name incorrectly.
A fault (defect) is introduced into the software as the result of an error. It is an anomaly in the software that may cause it to behave incorrectly, and not according to its specification.
Faults or defects are sometimes called “bugs.” Use of the latter term trivializes the impact faults have on software quality. Use of the term “defect” is also associated with software artifacts such as requirements and design documents. Defects occurring in these artifacts are also caused by errors and are usually detected in the review process.
A failure is the inability of a software system or component to perform its required functions within specified performance requirements.
During execution of a software component or system, a tester, developer, or user observes that it does not produce the expected results. In some cases a particular type of misbehavior indicates a certain type of fault is present. We can say that the type of misbehavior is a symptom of the fault. An experienced developer/tester will have a knowledge base of fault/symptoms/failure cases (fault models as described in Chapter 3) stored in memory. Incorrect behavior can include producing incorrect values for output variables, an incorrect response on the part of a device, or an incorrect image on a screen. During development failures are usually observed by testers, and faults are located and repaired by developers.
You can read the full chapter in Google Books, here.
There some different terms related to software bugs. Excerpt from a course I took:
Error: Human action or omission that results in a fault.
Fault: Fault is a software defect (incorrect step, process or data definition) that causes a failure.
Bug: Same as Fault.
Failure: The inability of a software to perform its required functions within specified performance requirements.
According to this, there is no difference between a defect and a bug. However, some people argue that bug is an error that is found before releasing the software, whereas defect is one found by the customer.
I couldn't resist posting the famous "first actual case of bug being found".
Back in the old days - defective operation of a computer was caused by all sorts of things - including rats chewing the wiring and real bugs (critters) getting into the works.
The term BUG has stuck as a term that means something not working as expected.
BUG should be thought of as a jargon term meaning a defect.
A defect is a technically correct term meaning that the thing does not do as it should.
Wherever possible, using DEFECT instead of BUG actually carries with it a connotation that we acknowledge our failures (our defects, our lack of understanding of user requirements or the things we overlooked in implementation) instead of dressing it up as the more trivial sounding "bug".
Try not to use the term BUG. Its silly, irrelevant, historical, and trivialising.
From the IEEE Standard Glossary of Software Engineering Terminology, which is cited in the Software Engineering Body of Knowledge KA for Software Testing and Software Quality:
bug. See: error; fault.
error. (1) The difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. For example, a difference of 30 meters between a computed result and the correct result. (2) An incorrect step, process, or data definition. For example, an incorrect instruction in a computer program. (3) An incorrect result. For example, a computed result of 12 when the correct result is 10. (4) A human action that produces an incorrect result. For example, an incorrect action on the part of a programmer or operator. Note: While all four definitions are commonly used, one distinction assigns definition 1 to the word “error,” definition 2 to the word “fault,” definition 3 to the word “failure,” and definition 4 to the word “mistake.” See a2so: dynamic error; fatal error; indigenous error; semantic error; syntactic error; static error; transient error.
failure. The inability of a system or component to perform its required functions within specified performance requirements. Note: The fault tolerance discipline distinguishes between a human action (a mistake), its manifestation (a hardware or software fault), the result of the fault (a failure), and the amount by which the result is incorrect (the error). See also: crash; dependent failure; exception; failure mode; failure rate; hard failure; incipient failure; independent failure; random failure; soft failure; stuck failure.
fault. (1) A defect in a hardware device or component; for example, a short circuit or broken wire. (2) An incorrect step, process, or data definition in a computer program. Note: This definition is used primarily by the fault tolerance discipline. In common usage, the terms “error” and “bug” are used to express this meaning. See also: data-sensitive fault; program sensitive fault; equivalent faults; fault masking; intermittent fault.
I think the definition of failure is the most relevant. Everything begins with a mistake, whether it's in the requirements, the design, the implementation, or the test case/procedure. If this mistake is manifested in software, it becomes a fault. A failure is caused by the existence of one or more faults in software.
I'm not to keen on the formal definition of error, though. I very much prefer the definition provided by dukeofgaming in his answer, however, the one in this answer is the IEEE standard definition of error.
Dan McGrath's answer nailed it right.
- A bug is the result of a coding error
- A defect is a deviation from the requirements
Maybe an example would make it clearer.
Example: Client wanted the web form to be able to save and close the window.
Scenario #1: Web form have a save button, and another close button. Result: Defect, because client wanted the 1 button to save and close the window. Developer misunderstood and created separately. Because both buttons performed their requirements, it is not a bug, but a defect because it didn't meet client's requirement.
Scenario #2: Web form have a save & close button, but only saves but does not close. Result: Bug. Because the button does not perform as required/expected. Developer knows it is suppose to produce that result but ultimately it didn't. (perhaps coding error)
Not sure if this makes it clearer.
p/s: from a developer stand point (I was once), both defects and bugs are just as important. We'll still fix it.
We even encountered weird anomalies, which we categorized under bugs and we continously try to figure out what is the cause and how to fix it. Terming it bugs doesn't make it trivial compared to defects.
Here is one I did earlier for my employer Q-LEAP based on the ISTQB vocabulary and I also checked the IEEE vocabulary. Enjoy.
Bug and Defect? The same even though one can have endless discussion about this. We have really other things to worry about, life is complicated enough already, etc.
An example of how the term is used in the wild, from "How Google Tests Software" p. 113. Open an article of "IEEE Software" and it's used the same way. Indeed, one rarely encounters the word "defect" in real life.
Life of a Bug
Bugs and bug reports are the one artifact every tester understands. Finding bugs, triaging bugs, fixing bugs, and regressing bugs are the heartbeat and workflow for software quality. This is the part of testing that is the most conventional at Google, but there are still a few interesting deviations from the norm. For this section, we ignore the bugs that are filed to track work items and use the term to identify actual broken code. As such, bugs often represent the hour-to-hour and day-to-day workflow for engineering teams.
A bug is born. Bugs are found and filed by everyone at Google. Product Managers file bugs when they catch issues in the early builds that differ form their specifications/thoughts. Developers file bugs when they realize they accidentally checked in an issue, or find an issue somewhere else in the codebase, or while dogfooding Google products. Bugs also come in from the field, from crowd-sourced testers, external vendor testing, and are filed by Community Managers monitoring the product-specific Google Groups. Many internal versions of apps also have quick one-click ways to file bugs, like Google maps. And, sometimes, software programs create bugs via an API.
The difference is that the term "bug" sound magical. As if a program can randomly have bugs in it after you're done programming. If it has random bugs then it means you didn't conform to the specifications and your program is in error.
A defect means an error where the program doesn't conform to the specifications. This is more severe and basically says, any error is a huge problem with the program and this means that the program is not fit to be released.
The difference is in the attitude of the programmers who use the terms. There are millions of programs that are released with bugs and people are fine with that because they accept for some reason that a bug is magical and random and that every program contains at least one bug. However, a programmer who uses the term "defect" may become uncomfortable with releasing a program with a defect because the term implies a greater severity.
The implications of preferring one term over the other affect us daily.
According to Dependability: basic concepts and terminology:
A system failure occurs when the delivered service deviates from fulfilling the system function, the latter being what the system is intended for. An error is that part of the system state which is liable to lead to subsequent failure: an error affecting the service is an indication that a failure occurs or has occurred. The adjudged or hypothesized cause of an error is a fault.
I understand defect as just another name for fault.
Bug is confusing and can represent a fault or a failure depending on the context.
Note that there is no mention of specification: even a spec can be faulty.
Outside of specific bug/task/ticket/defect/issue/whatever tracking system instance these words do not have any exact meaning and therefore discussing difference between them is pointless. When you are settling your workflow you should settle the terminology and provide descriptions.
In my current environment a "defect" is any item in Jira. Looks like Jira itself uses term "issue". We may have inherited it from some earlier system. "Bug" is a type of issue when something not working as expected and described in documentation. "Feature request" when something is working as expected but impvovement is desired (it can be obvious and important, but if the current behavior is described it is still a feature request). There are more types but those 2 are used by people outside of development team to ask something from it.
If you are picking names for issue types, "bug" and "defect" sound similar to me. Difference between them is stylistic. As English is not my native language I cannot really see much of it and not sure if what I see is correct.