Software defects: What they are and how to manage them

To win a battle, you must first understand your enemy intimately. If you want to deliver software with a minimal defect rate, it’s crucial to learn about software defects.

What is the nature of software defects? How are they born? What are the patterns in which they spread throughout a codebase? These are the types of questions we’ll cover in this post.

What is a software defect?

Definition

In an informal way, we can say that a defect is anything wrong with the application that prevents it from behaving in the expected way. In this sense, people often use “defects” and “bugs” interchangeably.

Put simply, your application has a defect if it has a problem that harms its ability to meet its requirements.

What is an example of a defect?

Software defect is a broad term; under its umbrella, there is an incredible variety of types of defects.

We’ll cover these categorizations in a minute; for now, let’s see some examples of software defects:

• A logistics API that should default to US when receiving a payload with a missing country, but crashes instead.
• A web form that incorrectly flags an entered phone number as invalid, preventing the form from being submitted.
• A broken layout of a web app while on mobile, preventing the user from reaching buttons or reading essential information.

When it comes to problems in a software application, you might find a variety of terms that people use interchangeably: errors, bugs, defects, failures, and more

What is an error vs. bug vs. defect?

When it comes to problems in a software application, you might find a variety of terms that people use interchangeably: errors, bugs, defects, failures, and more. Colloquially, there’s probably no harm in that. But it’s important to acknowledge that there are formal definitions for vocabulary words related to software problems, and as a software professional, you’d benefit from knowing them.

Let’s refer to the IEEE Standard Classification for Software Anomalies to learn the formal definitions of defect, error, failure, and fault:

• Defect: An imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs to be either repaired or replaced.
• Error: A human action that produces an incorrect result.
• Failure: Termination of the ability of a product to perform a required function or its inability to perform within previously specified limits.
• Fault: A manifestation of an error in software.

Example scenario: how errors lead to defects

So, based on the definitions above, let’s create a timeline for an example scenario.

Let’s say a programmer is writing code that makes a request to an endpoint, receives a JSON payload, deserializes that into an object, and tries to access a property of the object. However, that property can be null at times, and the programmer forgot to add a null check to access the property safely. That is an error.

The code is wrong, and the presence of wrong code in the application is a fault. When the changes are deployed to production and the new code is exercised thanks to user interaction, the application crashes when it reaches the faulty code. That prevents the program from performing its expected functions; in other words, a failure has occurred.

And what about the defect? As you’ve seen, that’s a broader term that means an imperfection in any kind of product. So, we can say that software faults are a subtype of defects. But for the purposes of this post, we’ll treat “software defects” and “software faults” as similar.

Types of software defects

Since “software defect” is such a broad term, there are many ways in which we can categorize them.

Categorizing by severity, defects can be:

• Critical defects. Defects that result in catastrophic failures that prevent the working of a critical area of the application.
• High, medium, or low severity defects. Defects of different severity, but which generally don’t prevent the usage of the application.

When it comes to whether a given defect affects functionality, there are two broader categories:

• Functional defects. Defects that prevent the application from behaving correctly regarding its functional requirements.
• Non-functional defects. Defects that cause problems for the end user, despite not preventing the application from doing its job properly. These defects include performance defects, usability defects, and all types of defects that, despite inconveniencing the users, don’t impact the core functionality of the system.

Causes of software defects

Software defects have many causes. They are complex and multifaceted and show up at different times during the software development life cycle.

During the initial phases of a project, when discovery is being done, the seeds for future software defects are often planted

Causes of software defects during requirements gathering

During the initial phases of a project, when discovery is being done, the seeds for future software defects are often planted. Many are the causes, but they can all be traced down to a single root: miscommunication.

Miscommunication can occur because the customers and the technical team don’t share a unified vocabulary, leading to misunderstandings. Miscommunication also occurs when both sides make assumptions about what the other side knows and wants, without asserting those assumptions out loud.

Finally, misuse of communication platforms can also lead to misunderstanding, such as people not using the proper channels of communication or services to share documents, resulting in different teams and stakeholders having different, often outdated versions of the same documents.

Causes of software defects during development

There are also plenty of opportunities for the introduction of defects once development starts. Miscommunication often plays a major role in this, particularly regarding requirements being communicated poorly to developers.

Inadequate planning also leads to defects. A lack of refinement sessions, or refinement done poorly, results in developers writing code that doesn’t handle edge cases, might not scale adequately, or doesn’t handle user devices in the expected way.

Of course, many defects happen thanks to the simple fact that programming is hard and developers are fallible human beings. Often, though, these errors end up resulting in defects because the team lacks mechanisms to prevent those errors from being deployed.

So, a non-exhaustive list of causes for programmer errors might include:

• Lack of engineering best practices related to quality, such as performing code reviews, writing unit tests and other forms of automated testing, establishing and following a coding standard, and more.
• Lack of automated checks, such as linters, statistical analyzers, and other types of analysis tools.
• Too much complexity in the codebase leads programmers to make mistakes.
• Inexperienced—often junior—developers working on legacy, complex, or undocumented codebases.

Detecting and managing defects

Up to this point, we’ve covered what software defects are, their types, and their causes. But how should a software organization go about tracking defects?

It has long been accepted that defects are cheaper to fix the sooner they are discovered.

I’ve previously presented a rough rule of thumb that early upstream defects generally cost 10-100 times as much to remove late downstream as they do to remove close to the point where they are created.

– Steve McConnell, An Ounce of Prevention

Economically, it makes a lot of sense for organizations to try to detect defects as early as possible in the development cycle. The greatest tool for that is having a comprehensive suite of automated testing, including at least unit tests, but also other types of testing as the organization sees fit.

Strategies for early defect detection

Other valuable tactics include:

• Code reviews—or alternatively, pair programming.
• Manual testing, particularly of the exploratory or ad-hoc fashion.
• User acceptance testing is carried out by/with actual end users of the application.
• Working in short cycles, gathering feedback after each one, and adjusting the approach used accordingly—in other words, Agile.

Once defects are discovered, they have to be triaged and fixed accordingly. You should have all defects tracked through tickets on your issue management system, with clear reproduction steps, as well as evidence of the defect and any other information that can help the programmer working to fix it.

Ideally, you should fix defects before working on new functionality. Pragmatically, not all defects are the same when it comes to their severity; often, it makes sense to ship with known bugs that are low or medium severity if that means not holding back shipping valuable new features.

It’s also recommended to collect data related to defects, so you can calculate and hopefully improve metrics such as MTTR (mean time to repair) and MTBF (mean time between failures).

In a nutshell:

• To avoid defects: Improve communication during the development process to prevent miscommunication, and employ best-of-breed software engineering practices to manage complexity and either avoid defects or have them caught early.
• To detect defects: Create a solid software testing strategy with comprehensive test automation and some manual testing where it makes sense, so defects are detected sooner rather than later.
• To fix defects: Manage them via your issue management system, adding plenty of details to the ticket so the programmer will know how to reproduce the error; triage and prioritize them according to their severity, fixing the most critical first.

Producing defect-free software is an impossible dream; delivering software with a minimal number of defects is a more feasible goal

Conclusion

Producing defect-free software is an impossible dream; delivering software with a minimal number of defects is a more feasible goal. However, achieving that goal requires understanding the nature and cause of software defects.

In this post, we’ve covered that and more. You now understand what software defects are and how they’re categorized. You also know their main causes and how to track and manage them effectively.

This post was written by Carlos Schults. Carlos is a skilled software engineer and an accomplished technical writer for various clients. His passion is to get to the bottom (the original source) of things and captivate readers with approachable and informative technical content.