bug
What is a bug?
In computer technology, a bug is a coding error in a computer program. (We consider a program to also include the microcode that is manufactured into a microprocessor.) The process of finding bugs -- before users do -- is called debugging. Debugging starts after the code is written and continues in stages as code is combined with other units of programming to form a software product, such as an operating system or an application.
Bugs are often discovered after a product is released or during public beta testing. When this occurs, users have to find a way to avoid using the buggy code or get a patch from the software developers.
A bug is just one kind of problem that a program can have. Programs can run bug-free and still be difficult to use or fail in some major objective. This kind of flaw is more difficult to test for. A well-designed program developed using a well-controlled process results in fewer bugs per thousands of lines of code. This is why it is important to include usability in testing.
Types of software bugs
Different kinds of bugs cause computers to malfunction. These are some of the most common types of computer bugs:
- Arithmetic. Sometimes referred to as calculation errors, arithmetic bugs are math errors in code that cause it not to function.
- Interface. An interface bug occurs when incompatible systems are connected to the computer. The problem can come from a piece of hardware or software. An application programming interface could be an example of an interfacing bug.
- Logic. These errors happen when the logic of the script causes the program to output the wrong information or get stuck and provide no output. One of example of a logic error is an infinite loop where a sequence of code runs continuously.
- Syntax. These bugs come from code written with the wrong characters. Different programming languages have different syntaxes, so using syntax from one could cause a bug in another.
- Teamwork. This is a bug that arises when there is miscommunication between programmers. One example is when there are differences between the product documentation and the product. Another example is when comments incorrectly describe the program code.
Another simple way to categorize bugs is from the user's perspective. These bug types include the following:
- Visual. A user can complete the chosen function, but something looks wrong with the application. This may be a problem with the responsive design of the application.
- Functional. A functional bug means that the program does not work as intended. For example, a user clicks the Save button, but the data is not saved.
Bugs may also be classified by the level of difficulty they cause for the user:
- Low-impact bugs have a minimal effect on user experience.
- High-impact ones affect some level of functionality, but the application is still usable.
- Critical bugs impede the application's main functionality.
Another approach to bug classification is to look at where they occur:
- Unit-level bugs are simple software bugs contained within one unit of code. They are typically due to calculation or logic errors and deal with one piece of software. They are usually easy to fix.
- System-level bugs are more complex bugs caused by multiple pieces of software interacting in ways that cause problems.
- Out-of-bound bugs arise when the user interacts with the program in an unexpected manner. For example, this happens when a user enters a parameter in a form field that the program is not designed to handle. Out-of-bound bugs can be used to exploit software. For instance, threat actors use the Infra:Halt vulnerability to carry out domain name system cache poisoning attacks on operational technology
How to prevent bugs
There are multiple ways to address bugs, depending on the type of bug and where and when they are found.
The development process
The best way to address programming errors is through prevention. The use of a sound software development process, such as the Agile and DevOps methodologies, can keep bugs from ever happening. Testing for quality is built into these development methodologies.
One such development practice is test-driven development. Tests should be created before a feature is coded to provide a standard against which to code it.
Another best practice is to use behavior-driven development, which encourages developers to code an application and document the process based on how a user is expected to interact with it.
Software testing
Testing is a way to discover bugs in software. The three types of software testing are the following:
- Functional testing involves testing the core functional pieces of a program for software errors before moving to the next testing stage. This part of the testing process confirms that all the pieces work. Functional testing is also called smoke testing.
- Exploratory testing involves techniques that test for less common software paths or ones that a normal functional test may miss. For example, one type of exploratory test is a coverage test that checks whether an application works on different devices, browsers or operating systems.
- Regression testing is designed to assess if previous changes made to the code caused an unintended problem. Regression testing consists of the following types:
Developers can prevent bugs from reaching users by testing early and often. Along with software testing, a peer code review with other developers, a senior developer or a quality assurance (QA) team can be useful.
Benchmarking
Benchmarking or benchmark testing establishes baseline performance expectations for software under different types of workloads. Benchmark tests can evaluate stability, responsiveness, speed and effectiveness of software.
Bugs that may lay dormant under one set of conditions may cause a serious problem in others. Benchmark testing can help identify such bugs. Some types of benchmarking are the following:
- Load benchmarking evaluates software systems under a specific load, which is often the usual amount of traffic expected for an application.
- Spike benchmarking evaluates software's performance during a sudden increase in workload.
- Breakpoint benchmarking pushes a piece of software to see how much stress it can handle before crashing.
How to fix bugs
Debugging
If a bug is found in software, it must be debugged. Debugging involves the following three steps:
- isolating the bug
- determining the root cause
- fixing the problem
It can be difficult for the programmers who wrote a piece of code to retrace their steps and look through complex and dense lines of code. A bug bounty program is one way to crowdsource a debugging effort. With crowdsourcing, software security researchers and ethical hackers are rewarded for finding problems and providing bug reports that reproduce or mitigate the vulnerability.
Continuous improvement
Organizations looking to minimize software bugs should balance the number of rollouts and rollbacks of software releases they do. By doing this, they ensure that the debugging process doesn't get in the way of a consistent software release schedule. This is generally what organizations working in an Agile development environment do.
Nevertheless, some bugs make it into the released product. Development teams can treat a release as part of the debugging process, gathering feedback on it, failing fast and making improvements.
A team or an individual on the team may schedule a fixed time each day to address software bugs. This way, gathering data on bugs and the debugging process itself become part of the daily schedule. A team can use data on the debugging process to estimate how long a particular fix will take and organize its efforts accordingly.
It is impossible to fix all bugs at once, and it takes time to collect the data needed to create accurate bug estimates. Programmers differ in skill levels and capabilities. And bug fix estimates may also vary among programmers working in different countries. Over time, a team can develop benchmark estimates for how many bugs it can fix in a month.
Debugging is never perfect or complete. New bugs always appear. Development teams should aim to address bugs efficiently and deliver net-positive value to stakeholders with each software release.
History of software bugs
The word bug originated in engineering. The use of the term in computing is attributed to pioneer programmer Grace Hopper. In 1944, Hopper was a young Naval Reserve officer who worked on the Mark I computer at Harvard. Hopper later described an incident in which a technician is said to have pulled an actual bug -- a moth, in fact -- from between two electrical relays in a Mark II computer. The Navy had the moth on display for many years. The Smithsonian now has it in its holdings.
Although bugs typically cause annoying computer glitches, their impact can be more serious. A 2005 Wired article about the 10 worst software bugs in history reported that bugs had caused major explosions, crippled space probes and killed people. For example, in 1982, a system -- allegedly implanted by the Central Intelligence Agency -- controlling the Trans-Siberian gas pipeline caused the largest non-nuclear explosion in history.
The article also said, between 1985 and 1987, a bug, called a race condition, in a radiation therapy device resulted in the delivery of lethal doses of radiation, killing five people and injuring others. In 2005, Toyota recalled 160,000 Priuses because a bug caused warning lights to come on and the engine to stall for no reason.
Another notable bug incident occurred in 2016 when Tesla's Autopilot feature malfunctioned. It failed to distinguish a white tractor trailer crossing the highway against a bright sky, causing the car to crash, which resulted in a fatality.
Learn how automating QA can speed up testing and debugging.
