Software Defects

Categories of Software Defects

A careful review of the software quality literature reveals that the overall ambiguity in defining what
"quality" means has carried over into the definition of software defects.
There seems to be no effective and generally agreed to taxonomy of software defect categories.

Other industries which have explicit warranties for their products (unlike software which usually is not
warrantied). Assuming that software will eventually begin to issue warranties, what are the kinds of
defects that are likely to trigger warranty repairs if they reach customers.

For warranty purposes, there are four general categories of software defects that are of concern because
they tend to be significant in product liability litigation:

1. Errors of commission, where something is done that is wrong.

A classic example at the code level would be going through a loop one time too many or branching
to the wrong address.
An example of this kind of error at the specification level was noted in an IBM software
specification where the data format for information being transmitted was different from the
format expected by the receive function of the same application.
An example of this kind of problem in user manuals is frequently found in usage instructions,
where the command sequence in the user manual differs from what the software really uses. Many
applications are shipped with "READ MW files which explain last-minute changes that were noted
after printing of manuals occurred.

2. Errors of omission, where something was left out by accident.

A minor but common example for code would be omitting one of the parentheses in nested
expressions. In requirements and specifications, another common error of omission is to leave out
discussions of opposites. For example, a specification might say "users must enter a valid personal
security code to access the system" but fail to say what occurs if the user enters an invalid code or
none at all.
A very serious design omission which turned into a code omission as well was forgetting to
include calculations for February 29th, leap year, in the calendar routine for a software security
program. All users were locked out at midnight on February 28th since the 29th was not
recognised as a valid date.

3. Errors of clarity and ambiguity, where two people reach different interpretations of what
is meant.
This kind of error is common with all natural language requirements and specification documents
and user manuals, too. This error can occur with code also, and especially for languages such as
APL that are difficult to sight read.
A trivial example of natural language ambiguity is the expression "time flies like an arrow." The
obvious meaning is about the rapid passage of time. However, a legitimate alternative meaning
would be that creatures called "time flies" are fond of arrows.

4. Errors of speed or capacity where the application works, but not fast enough.
A classic example of this kind of error was noted during testing of an ITT telephone switching
system, where performance was adequate for a few calls, but degraded to unacceptable levels as
the number of simultaneous calls climbed above 20.
A more recent example is that of the driver's license query system developed for the State of New
Jersey, where the response time to query the status of a driver's license sometimes ran to more than
60 minutes when simultaneous queries were being made. The anticipated time for queries was less
than 30 seconds.

Software defects can be found in any of hundreds of documents and work products including very
serious ones in cost estimates and development plans. However, there are seven major classes of
software work products where bugs or defects have a strong probability of triggering some kind of
request for warranty repair if they reach the field.

1/9
 Software Defects

The seven categories which follow are the major origin points of problems which have a strong impact
on clients' ability to use the software once it is deployed:

1) Errors in Requirements
2) Errors in Design
3) Errors in Source Code
4) Errors in User Documentation
5) Errors due to "Bad Fixes"
6) Errors in Data and Tables
7) Errors in Test Cases

There are hundreds of possible kinds of errors overall with no easy or tidy way of summarising the
most troublesome subtypes. The best that can be done is to consider examples of the more common
kinds of defects in each origin point

Requirements Defects (1)

All four categories of defect are found in requirements, although the two most common problems are
errors of omission and errors of clarity and ambiguity. A significant and important aspect of
requirements errors is that if they are not prevented or removed, they usually flow downstream into
design, code, and user manuals. Historically, errors which originate in requirements tend to be the most
expensive and troublesome to eliminate later. Therefore every effort should be devoted to minimising
requirements problems. For reducing requirements defects, prevention is usually more effective than
defect removal.

Errors of omission are the most common form of requirements defects.

For example, a user requirement for a software estimating tool might state "the application shall
perform software cost estimates." In reality, what was intended would be something more like "the
application shall perform sizing predictions for specifications, source code, and user manuals; software
staffing predictions for technical employees and management; software schedule predictions from
requirements through delivery; and software cost estimates for the activities of requirements, analysis,
design, coding, quality assurance, testing, technical writing, and project management."

The requirement that software applications store dates in two-digit format was one of the most
expensive problems in human history. To conserve storage, many applications recorded the year as a
two-digit number; i.e., 1996 is recorded as 96. For government software at least, this two-digit format
was a formal requirement, and also a terrible mistake. Although the Year 2000 problem originated in
requirements, it also permeated the design and code of many thousands of software applications.

The Year 2000 problem also illustrates that defining quality as "conformance to requirements" is a
hazardous practice since requirements themselves are the source of the most expensive and
troublesome errors that software systems contain.

It is an interesting question as to whether requirements for large systems can ever be complete,
given the observed rate of creeping requirements during the development cycle. Since requirements
grow at rates between 1% and 3% per month during development, the initial requirements often
describe less than 50% of the features that end up in the final version when it is delivered.
Once deployed, applications continue to change at rates that approximate 5% to 8% new features every
year, and perhaps 10% modification to existing features.

The second most common kind of requirements defect is the clarity and ambiguity defect.
The following paragraph is from an actual software requirement and illustrates how poor natural
language is for expressing software concepts:

2/9
 Software Defects

"The GPSS assembler is a two-pass program consisting of the DAG03 and DAG03 modules. Two
intermediate data sets are employed between passes to retain original card images for listing purposes
and partially processed card images which are used as input to the second pass. This method of
operation enables the program to handle any size module and to be limited by memory size only for the
number of symbols which may be retained and not by the number of input records."

The main problem with this paragraph is the use of "and" to create very long pairs of compound
conditions. This construction puts a severe burden on human temporary memory capacity, which is
limited to roughly seven words per topic.

Thoughtful researchers such as Torn DeMarco have noted that requirements based on natural language
will always be troublesome. Several formal requirements methods have been developed such as:

 DeMarco's structured English with a well defined vocabulary and syntax,

 IBM's HIPO diagrams (Hierarchy plus Input, Processing, Output),
 the Problems Statement Language (M),
 Warnier-Orr Diagrams,
 the Structured Analysis and Design (SADT) technique
 and quite a few more.

However, all of these more formal approaches make demands that the clients of software learn the
method; hence they are not widely used.

Requirements can also contain errors of commission, or things that are just plain wrong or mutually
contradictory. For example, a state motor vehicle registration processing system contained two
conflicting requirements:
1) proof of valid insurance must be input to issue the registration; and
2) in another place the requirement called for inputting registration information prior to issuing a
proof of insurance.
In other words, the requirement contained a deadlock that would have prevented both the registration
and the insurance proof from being issued since each required that the other come first.

Design Defects (2)

All four categories of defects are found in software design and specifications, as might be expected.
The most common forms of design defects are errors of omission where things are left out, and of
commission, where something is stated that later turns out to be wrong.
Errors of clarity and ambiguity are also common, and many performance related problems originate in
the design process as well.

Design ranks next to requirements as a source of very troublesome, and very expensive errors.

Here, too, a combination of defect prevention and defect removal is needed for success.
However, formal design inspections are used by "best in class" software producers for major software
applications. Formal design inspections are one of the most powerful and successful software quality
approaches of all time, with a 30-year track record of success and one of the best returns on investment
(R01) of any known software engineering technology.

As an example of an error of commission, an early suite of office support tools (i.e., word processing,
spreadsheet, database, graphics, etc.) was obviously designed by different teams, since the key
specified for "HELP" in one portion of the application was specified as the "DELETE" key in another
portion of the application.
Not only was this anomaly in the design, but the code was actually implemented with the same key
alternating between HELP and DELETE functions based on which application was in use.
External Beta testers usually found this problem when they accidentally deleted all of their work when
they thought they were asking for help. The design was revised, and indeed the problem helped to
trigger the more or less standard definition of using F l as a help key in many applications.

The second common category of design defect are errors of omission.

3/9
 Software Defects

In fairness, it is not clear if it is technically possible to specify all of the features and functions in a
large software system. If a system the size of Microsoft Windows 95 or IBM's MVS in the 90,000
function point size range were in fact fully specified, the volume of specifications would approach or
even exceed the lifetime reading speed of a single individual.
The total volume of specifications could exceed 500,000 pages.

The completeness of software specifications declines as system size increases (over 1000fp.)

The study of software design found some other interesting topics. For example, the minimum set of
specifications for an IBM software product discussed seven fundamental topics, and eight important
but secondary topics. Errors in both the fundamental and secondary design topics are useful to consider.

Errors in Seven Fundamental Design Topics

1) Functions Performed
Errors in descriptions of functions the application will perform, are often errors of omission, where a
particular function is accidentally omitted. Often the omitted ones are implied functions rather than
those explicitly demanded by users.
For example, if a software cost estimating program is designed to perform long-range maintenance
estimates that may span five years or more, there is an implied need to include inflation rate
adjustments over the same time periods. Implied functions such as the need for inflation rate
adjustments often are forgotten in both requirements and design.

2) Function Installation, Invocation, Control, and Termination

Errors in how features, or even entire applications, should be installed are surprisingly common.
At a lower level, information on how to start-up a feature, control its behaviour, and safely turn off the
feature when finished are also common for both commercial and in-house software.
Numerically, errors of this class constitute almost 50% of the problems reported to commercial
software vendors by users.

3) Data Elements
Errors in describing the data used by the application are a major source of problems downstream during
coding and testing. A minor example of errors due to inadequate design of data elements can be seen in
many programs that record addresses and telephone numbers. Often, insufficient space is reserved for
names, or topics such as dealing with e-mail addresses as well as phone numbers are omitted.

4) Data Relationships
Errors in describing data relationships are very common and a source of much trouble later.
A major problem involving data relationships actually occurred in a government agency when payroll
and income tax calculations were first automated. Because of a design problem that did not ensure
correct linkage of employee names with mailing addresses, every W2 tax form prepared by the
agency's new software was mailed to the address of the person whose name was next in alphabetic
sequence.

5) Structure of the Application

It is a well-known phenomenon that complex software structures with convoluted control flow tend to
have high error rates. Poor structural design has been fairly common, and is often due to haste or to
poor training and preparation.
Many commercial tools can measure the cyclomatic and essential complexity of programs or systems.
The problem is that once the systems are developed in a complex fashion, it may be too late.
There are also commercial tools that can analyse complexity and restructure and simplify it.
Although such tools are effective, prevention is often better than attempting a cure after the fact.

6) Sequences or Concurrency of Execution

Many errors of speed and capacity have their origin in failing to design for optimum performance.
The most common reasons for poor performance are things like complex control flow and excessive
branching, or too many sequential operations when parallel processing would lead to faster throughput.
Also, minimising external operations such as getting and putting data during performance-sensitive
operations is significant.

4/9
 Software Defects

7) Interfaces
Interface errors between human users and software, and between related software packages, are a
chronic problem for software designers and developers.
One example of interface errors is sending and receiving applications with incompatible data formats.

Errors in Eight Secondary Design Topics

The seven fundamental design issues actually describe the application itself. Therefore errors or defects
affect what the software actually does.
The eight secondary topics describe various targets and goals, plus the hardware and software context
of the application. Errors in the secondary topics are often errors or omission, although the other
classes of errors are plentiful, too.

1) Security
As hackers and viruses become trickier and more common, every application that deals with business
information needs to have security features designed into it. Errors in software security can result in
viral invasion or easy penetration by malicious hackers.

2) Reliability
This section of software specifications defines the mean time to failure and mean time between failures
targeted for the application. For contract software, reliability requirements should be stated explicitly.
There is a strong correlation between reliability and software defect volumes and severity levels, so
reliability targets lead directly to the need for effective defect prevention and defect removal
operations. In some software development contracts, explicit targets for defect removal efficiency and
post-release quality levels are now included.

3) Maintainability
This section of specifications discusses the assumptions of how software defects will be reported and
handled, plus any built-in features of the application to facilitate later maintenance activity. Topics such
as maintenance release intervals are also discussed.

4) Performance
This section discusses the throughput, transaction rates, and other targets for performance that the
application is intended to achieve. Performance targets originate with requirements, but how they will
be achieved is a major topic of the design process. Errors in performance design can lead to severe
problems, including cancellation of the project or litigation for breach of contract.

5) Human Factors
This section discusses the need for training and tutorial information to ease users into full
understanding of how the application operates. The human factors section also discusses screen
layouts, buttons, pull-down menus, and other aspects of modern graphical user interfaces. Errors in this
section can lead to notable complaints from users and low levels of user-satisfaction.

6) Hardware Dependencie5
This section discusses the platforms on which the application will operate, and any special hardware
drivers of devices that may also be necessary. Errors in this section may trigger substantial rework to
add new hardware capabilities.

7) Software Dependencies
This section discusses other software packages that may be necessary in order for the application to
operate. Errors in this section can lead to reduced functionality. A by-product of listing specific
software dependencies is the ability to explore interfaces in a thorough manner.

8) Packaging
This section, used primarily by commercial software vendors, discusses how the software will be
packaged and delivered; i.e., CD-ROM, disk, down-loaded from a host, etc. Errors here may affect
user-satisfaction and market shares. Also, the initial packaging decision will probably affect how
subsequent maintenance releases and defect repairs are distributed to users also.

5/9
 Software Defects

For example, starting in about 1993 many major software vendors began to use commercial networks
such as America Online, CompuServe, and the Internet as a channel for receiving customer queries and
defect reports and also as a channel for down-loading updates, new releases, and defect repairs.

Coding Defects (3)

All four categories of defects can be found in source code, with errors of commission being dominant
while code is actually under development. Perhaps the most surprising aspect of coding defects when
they are studied carefully is that more than 50% of the serious bugs or errors found in the source code
did not truly originate in the source code.

A majority of so-called programming errors are really due to the programmer not understanding
the design, or the design not correctly interpreting a requirement.

Given the previous discussion of design errors, this is not a surprising situation. Software is one of the
most difficult products in human history to visualise prior to having to build it, although complex
electronic circuits have the same characteristic.

The built-in syntax checkers and editors associated with modern programming languages can find
many "true" programming errors such as missed parentheses or looping problems almost as soon as the
programmer finishes the keystrokes. Even poor structure and excessive branching can now be
measured and corrected automatically.

The kinds of errors that are not easily found are deeper problems in algorithms or those associated with
misinterpretation of design.

At least 500 different programming languages are in use, and the characteristics of the languages
themselves interact with factors such as human attention spans and the capacities of temporary
memory. This means that each language, or family of languages, tends to have common patterns of
defects but the patterns are not the same from language-to-language.

Languages with highly complex syntax and arcane symbology tend to accumulate errors based on
lapses in programmer attention spans or saturation of human temporary memory.
Some older languages, such as assembly language, did not have much in the way of programming
environments with built-in syntax checkers, code editors, and the like. Therefore the mechanical
problems caused by typographical errors that were troublesome for some older languages are not really
a problem with modern languages and their environments.

Programming in any language is a complex, intellectual challenge with a high probability of making
mistakes from time to time. To make an analogy, most of us see occasional typographical errors when
reading daily newspapers. Any major software application will have more source code statements than
a daily newspaper has English words. The probability of making errors is higher with source code than
with English text. The methods for finding errors are not as effective as proof reading text documents.
Therefore software applications are likely to contain errors unless extraordinary approaches are used to
eliminate them.

Defects in low-level Procedural Languages

In any programming language there can be errors based on misinterpretation of design issues or poorly
designed algorithms. These errors are not really caused by programming languages, but rather are
caused by upstream problems in requirements, design, prototyping, or what the programmer does
before coding commences.

For languages such as assembly language, C, FORTRAN, and COBOL syntactic errors are common.
Also common are errors equivalent to typographical errors such as omitting a parenthesis, or inverting
logical symbols (i.e., using " > " when 11 < " was intended).

Since low-level languages often manipulate registers and require that programmers set up their own
loop controls, common errors involve failure to initialise registers or going through loops the wrong
number of times.

6/9
 Software Defects

Other common problems with low-level procedural languages involve allocating space or ensuring that
data or subroutines do not accidentally overlay portions of programs. Also, embedded constants or data
values can be troublesome.

For languages that are weakly-typed, which is to say have no built-in safeguards for ensuring that
numbers and text are not accidentally mixed together when performing calculations, errors involving
mismatched data types are common. Of course for all programming languages, branching errors are
endemic. That is, branching to the wrong location for execution of the next code segment.

It is interesting that there is no solid empirical data that strongly-typed languages have lower
defect rates than weakly-typed languages, although there is no counter evidence either.

Defects in High-Level Non-Procedural Languages

Many higher-level languages, such as Ada and Modula were designed to minimise certain common
kinds of errors, such as mixing data types or looping an incorrect number of times.
Of course, typographical and syntactic errors can still occur, but the more troublesome errors have to
do with logic problems or incorrect algorithms.

A common form of error with both non-procedural and procedural languages has to do with retrieving,
storing, and validating data. It may sometimes happen that the wrong data is requested, or only part of
the data.

The major problems noted in high-level non-procedural languages are those that originated upstream
but find their way into the code: poorly designed algorithms, misinterpretation of design, and
ambiguous requirements that do not become clear until the client sees the screen and the way the
software operates.

Defects in Object-Oriented Programming Languages

Object-oriented (OO) programming languages such as SMALLTALK and ObjectiveC can contain
syntactical errors. Errors also can be inherited due to nature of the object-oriented paradigm.
However, the programming environments associated with many object-oriented programming
languages are fairly effective in finding "mechanical" errors such as simple typographical errors.

With OO programming languages, the more difficult problems are those that originated upstream, such
as poorly designed algorithms. Indeed, since OO analysis and design has a steep learning curve and
is difficult to absorb, some OO projects suffer from worse than average quality levels due to
problems originating in the design.

Documentation Defects (4)

User documentation in the form of both manuals and online information can contain errors of omission
and errors of commission, but the most common kind of problem is that of errors of clarity and
ambiguity. Performance-related errors are seldom encountered in user information.

The most troublesome problems in user manuals are found in examples and instructions for invoking or
controlling certain features, such as installing the software, using it, and shutting it down.

About five years ago, many newspapers, including the Boston Globe, ran a short article about error in a
release of the WordPerfect text processing application. According to the Boston Globe, an error in the
instructions for installing the release of this very popular word processing package led to more than
10,000 simultaneous phone calls to the vendor which temporarily saturated and shut down the phone
system in the State of Utah.

Fix Defects (5)

The software quality literature has not discussed bad fix problems to the level indicated by the
seriousness of the topic. The phrase "bad fixes" refers to attempts to repair an error which, although the
original error may be fixed, introduce a new secondary bug into the application. Bad fixes are usually
errors of commission, and they are found in every major deliverable although most troublesome for
requirements, design, and source code.

7/9
 Software Defects

Bad fixes are very common and can be both annoying and serious.
From limited surveys of commercial software programming personnel, from about 5% to more than
20% of attempts to repair bugs may create a new secondary bug.

For code repairs, bad fixes correlate strongly with high complexity levels, as might be expected.
This means that repairs to ageing legacy applications where the code is poorly structured and resembles
a "spaghetti bowl" in terms of loops and control flows tend to achieve higher than average bad fix
injection rates.

Examples of common kinds of bad fixes include the following:

1) when attempting to correct a loop problem such as going through the loop one time too often,
the repair goes through the loop one time short of the correct amount; and
2) when correcting a branching problem that goes to the wrong subroutine, the repair goes to a
different wrong subroutine.

Often bad fixes are the result of haste or schedule pressures which cause the developers to skimp on
things like inspecting or testing the repairs. Failure to validate repairs is a hazardous practice for
software.

Data Defects (6)

The topic of data quality and data defects is usually outside the domain of software quality assurance
since most data is not an integral part of the software, but is added later by users once the software is
deployed and in use. This is true for database packages such as Access, Paradox, IBM's Information
Management System (IMS), Oracle, Alpha IV, and many others.

Since one of the most common business uses of computers is specifically to hold databases,
repositories, and data warehouses the topic of data quality is becoming a major issue.
Data errors can be very serious and they also interact with software errors to create many expensive
and troublesome problems. Consider the implications of data errors in credit history files, where a
consumer is given a bad credit rating due to a mix up with someone who has a similar name.

Many of the most frustrating problems that human beings note with computerised applications can be
traced back to data problems. Errors in utility bills, financial statements, tax errors, motor vehicle
registrations, and a host of others are often data errors.

As computers and software become the dominant tools for storing business, personal, legal, and
military information the topics of data quality, data errors, and data security are going to grow in
importance in the 21st century.

Test Case Defects (7)

The literature on software quality seriously understates quality problems with both test plans and test
cases themselves. Some exploratory research carried out by IBM's software quality assurance group on
regression test libraries noted some disturbing findings:

 About 30% of the regression test cases were duplicates that could be removed without
reducing testing effectiveness.
 About 12% of the regression test cases contained errors of some kind.
 Coverage of the regression test library ranged between about 40% and 70% of the code; i.e.,
there were notable gaps which none of the regression test cases managed to reach.

Regression
For software this means slipping backward, and usually refers to an error made while
attempting to add new features or fix bugs in an existing application. A regression test means a
set of test cases that are run after changes are made to an application. The test cases are
intended to ensure that every prior feature of the application still works, and that the new
materials have not caused errors in existing portions of the application.

8/9
 Software Defects

Among the common kinds of errors noted for test cases were:
1) failure of the test-case to check for limits or boundary conditions;
2) errors in data that is part of the test-case; and
3) omission of certain conditions that should be tested, such as testing only three out of four
possible outcomes.

Some concrete examples of errors noted over the years in test cases include things such as failing to
test that enough space had been reserved for printing overtime payment reports.
It happened that when monthly overtime exceeded $999.99 the high-order digit disappeared.

Errors in test-case construction, like many coding errors, can be traced back to misunderstanding or
ambiguities in the specifications and even the requirements.
So long as natural language text is a dominant part of software design, we can expect errors of
commission, omission, and ambiguity to remain common and troublesome.

9/9