Software bug


A software bug is a defect in computer software. A computer program with many or serious bugs may be described as buggy.
The effects of a software bug range from minor to severe.
In 2002, a study commissioned by the US Department of Commerce's National Institute of Standards and Technology concluded that "software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually, or about 0.6 percent of the gross domestic product".
Since the 1950s, some computer systems have been designed to detect or auto-correct various software errors during operations.

History

Terminology

Mistake metamorphism refers to the evolution of a defect in the final stage of software deployment. Transformation of a mistake committed by an analyst in the early stages of the software development lifecycle, which leads to a defect in the final stage of the cycle has been called mistake metamorphism.
Different stages of a mistake in the development cycle may be described as mistake,anomaly, fault, failure, error, exception, crash, glitch, bug, defect, incident, or side effect.

Examples

Software bugs have been linked to disasters.
Sometimes the use of bug to describe the behavior of software is contentious due to perception. Some suggest that the term should be abandoned, contending that bug implies that the defect arose on its own, and push to use defect instead, since it more clearly indicates they are caused by a human.
Some contend that bug may be used to cover up an intentional design decision. In 2011, after receiving scrutiny from US Senator Al Franken for recording and storing users' locations in unencrypted files,
Apple called the behavior a bug. However, Justin Brookman of the Center for Democracy and Technology directly challenged that portrayal, stating "I'm glad that they are fixing what they call bugs, but I take exception with their strong denial that they track users."

Prevention

Preventing bugs as early as possible in the software development process is a target of investment and innovation.

Language support

Newer programming languages tend to be designed to prevent common bugs based on vulnerabilities of existing languages. Lessons learned from older languages such as BASIC and C are used to inform the design of later languages such as C# and Rust.
A compiled language allows for detecting some typos before runtime which is earlier in the software development process than for an interpreted language.
Languages may include features such as a static type system, restricted namespaces and modular programming. For example, for a typed, compiled language :
float num = "3";
is syntactically correct, but fails type checking since the right side, a string, cannot be assigned to a float variable. Compilation fails forcing this defect to be fixed before development progress can resume. With an interpreted language, a failure would not occur until later at runtime.
Some languages exclude features that easily lead to bugs, at the expense of slower performance the principle being that it is usually better to write simpler, slower correct code than complicated, buggy code. For example, Java does not support pointer arithmetic which can be very fast but may lead to memory corruption or segmentation faults if not used with great caution.
Some languages include features that add runtime overhead in order to prevent common bugs. For example, many languages include runtime bounds checking and a way to recover from out-of-bounds errors instead of crashing.

Techniques

and defensive programming can prevent easy-to-miss typographical errors.
For example, most C-family programming languages allow the omission of braces around an instruction block if there's only a single instruction. The following code executes function only if is true:
if
foo;
But this code always executes :
if ;
foo;
Using braces - even if they're not strictly required - reliably prevents this error:
if
Enforcement of conventions may be manual or via automated tools such as linters.

Specification

Some contend that writing a program specification, which states the intended behavior of a program, can prevent bugs. Others, however, contend that formal specifications are impractical for anything but the shortest programs, because of problems of combinatorial explosion and indeterminacy.

Software testing

One goal of software testing is to find bugs. Measurements during testing can provide an estimate of the number of likely bugs remaining. This becomes more reliable the longer a product is tested and developed.

Agile practices

may involve frequent software releases with relatively small changes. Defects are revealed by user feedback.
With test-driven development, unit tests are written while writing the production code, and the production code is not considered complete until all tests have been written and complete successfully.

Static analysis

Tools for static code analysis help developers by inspecting the program text beyond the compiler's capabilities to spot potential problems. Although in general the problem of finding all programming errors given a specification is not solvable, these tools exploit the fact that human programmers tend to make certain kinds of simple mistakes when writing software.

Instrumentation

Tools to monitor the performance of the software as it is running, either specifically to find problems such as bottlenecks or to give assurance as to correct working, may be embedded in the code explicitly, or provided as tools. It is often a surprise to find that most of the time is taken by a piece of code, and this removal of assumptions might cause the code to be rewritten.

Open source

development allows anyone to examine source code. A school of thought popularized by Eric S. Raymond as Linus's law says that popular open-source software has more chance of having few or no bugs than other software, because "given enough eyeballs, all bugs are shallow". This assertion has been disputed, however: computer security specialist Elias Levy wrote that "it is easy to hide vulnerabilities in complex, little understood and undocumented source code," because, "even if people are reviewing the code, that doesn't mean they're qualified to do so." An example of an open-source software bug was the 2008 OpenSSL vulnerability in Debian.

Debugging

Debugging can be a significant part of the software development lifecycle. Maurice Wilkes, an early computing pioneer, described his realization in the late 1940s that
"a good part of the remainder of my life was going to be spent in finding errors in my own programs".
Typically, the first step in locating a bug is to reproduce it reliably. If unable to reproduce the issue, a programmer cannot find the cause of the bug and therefore cannot fix it.
Some bugs are revealed by inputs that may be difficult to reproduce. One cause of the Therac-25 radiation machine deaths was a bug that occurred only when the machine operator very rapidly entered a treatment plan; it took days of practice to become able to do this, so the bug did not manifest in testing or when the manufacturer attempted to reproduce it. Other bugs may stop occurring whenever the setup is augmented to help find the bug, such as running the program with a debugger; these are called heisenbugs.
Sometimes, a bug is not an isolated flaw, but represents an error of thinking or planning on the part of the programmers. Often, such a logic error requires a section of the program to be overhauled or rewritten. a process known as code refactoring.
A code review, stepping through the code and imagining or transcribing the execution process, may often find errors without ever reproducing the bug as such.
A program known as a debugger can help a programmer find faulty code by examining the inner workings of a program, such as executing code line-by-line and viewing variable values.
As an alternative to using a debugger, code may be instrumented with logic to output debug information to trace program execution and view values. Output is typically to console, window, log file or a hardware output, potentially driving an indicator LED.
Since the 1990s, particularly following the Ariane 5 Flight 501 disaster, interest in automated aids to debugging rose, such as static code analysis by abstract interpretation.
In an embedded system, the software is often modified to work around a hardware bug since software modifications can be cheaper and less disruptive than modifying the hardware.

Management

Bugs are managed via activities like documenting, categorizing, assigning, reproducing, correcting and releasing the corrected code.
Tools are often used to track bugs and other issues with software. Typically, different tools are used by the software development team to track their workload than by customer service to track user feedback.
A tracked item is often called bug, defect, ticket, issue, feature, or for agile software development, story or epic. Items are often categorized by aspects such as severity, priority and version number affected.
In a process sometimes called triage, choices are made for each bug about whether and when to fix it based on information such as the bug's severity and priority and external factors such as development schedules. Triage generally does not include an investigation into the cause. Triage may occur regularly and minimally consists of reviewing new bugs since the previous triage, possibly extending to all open bugs. Attendees may include the project manager, the development manager, the test manager, the build manager, and technical experts.