project data). A new bug is initially
unconfirmed. Once reproduced, it is changed to
confirmed. Once the issue is resolved, it is changed to
fixed. 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(s) 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.
Severity Severity is a measure of the impact the bug has. This impact may be data loss, financial, loss of goodwill, and wasted effort. Severity levels are not standardized, but differ by context, such as industry and tracking tool. For example, a crash in a video game has a different impact than a crash in a bank server. Example severity level descriptions are
crash or hang,
no workaround (user cannot accomplish a task),
has workaround (user can still accomplish the task),
visual defect (a misspelling for example), or
documentation error. Another example set of severities:
critical,
high,
low,
blocker,
trivial. The severity of a bug may be the same category as its priority for being fixed, or the two may be quantified and managed separately. A bug severe enough to delay the release of the product is called a
show stopper.
Priority Priority describes the importance of resolving the bug in relation to other bugs. Priorities might be numerical, such as 1 through 5, or named, such as
critical,
high,
low, and
deferred. The values might be similar or identical to severity ratings, even though priority is a different aspect. Priority may be a combination of the bug's severity and the level of effort to fix. A bug with low severity but easy to fix may get a higher priority than a bug with moderate severity that requires significantly more effort to fix.
Patch A bug of sufficiently high priority may warrant a special release to fix it. Such a release is sometimes called a
patch.
Maintenance release A software release that emphasizes bug fixes may be called a
maintenance release to differentiate it from a release that emphasizes new features or other changes.
Known issue It is common practice to release software with known, low-priority bugs or other issues. Possible reasons include but are not limited to: • A deadline must be met and resources are insufficient to fix all bugs by the deadline • The bug is already fixed in an upcoming release, and it is not of high priority • It may be suspected, or known, that some users are relying on the existing buggy behavior; a proposed fix may introduce a
breaking change • The problem is in an area that will be obsolete with an upcoming release; fixing it is unnecessary • "It's not a bug, it's a feature" A misunderstanding exists between expected and actual behavior or
undocumented features.
Implications The amount and type of damage a software bug may cause affects decision-making, processes, and policy regarding software quality. In applications such as
human spaceflight,
aviation,
nuclear power,
health care,
public transport, or
automotive safety, since software flaws have the potential to cause human injury or even death, such software will have far more scrutiny and quality control than, for example, an online shopping website. In applications such as banking, where software flaws have the potential to cause serious financial damage to a bank or its customers, quality control is also more important than, say, a photo editing application. Other than the damage caused by bugs, some of their cost is due to the effort invested in fixing them. In 1978, Lientz et al. showed that the median of projects invest 17 percent of their development effort in bug fixing. In 2020, research on
GitHub repositories showed the median is 20 percent.
Cost In 1994, NASA's
Goddard Space Flight Center managed to reduce their average number of errors from 4.5 per 1,000 lines of code (
SLOC) down to 1 per 1000 SLOC. This figure is iterated in literature such as
Code Complete by
Steve McConnell, and the
NASA study on Flight Software Complexity. Some projects even attained zero defects: the
firmware in the
IBM Wheelwriter typewriter which consists of 63,000 SLOC, and the
Space Shuttle software with 500,000 SLOC. is a benchmark of 185 C bugs in nine open-source programs. • Defects4J is a benchmark of 341 Java bugs from 5 open-source projects. It contains the corresponding patches, which cover a variety of patch types. ==Types==