A Taxonomy for Bugs
There is no universally correct way to categorize bugs.
The taxonomy is not rigid.
A given bug can be put into one or another category
depending on its history and the programmer’s state of mind.
• The major categories are:
1. Requirements, features and functionality Bugs
2. Structural Bugs
3. Data Bugs
4. Coding Bugs
5. Interface, integration and system Bugs
6. Test and Test Design Bugs
1. Requirements, features and
functionality Bugs
Various categories in Requirements, Features and
Functionality Bugs:
They are:
1. Requirements and Specifications
2. Feature Bugs
3. Feature Interaction Bugs
1.1 Requirements and Specifications Bugs
• Requirement and Specification: Requirements and the
specifications developed from them can be incomplete,
ambiguous, or self-contradictory. They can be
misunderstood or impossible to understand.
• The specifications that don’t have flaws in them may
change while the design in progress. The features are
added, modified and deleted.
• Requirements, especially as expressed in a specification
are a major source of expensive bugs.
• The range is from a few percentage to more than 50%,
depending upon the application and the environment.
• What hurts most about these bugs is that they’re the
earliest to invade the system and the last to leave .
1.2 Feature Bugs
• Feature Bugs: Specification problems usually create
corresponding feature problems. A feature can be
wrong, missing, or superfluous. A missing feature or case
is easier to detect and correct.
• A wrong feature could have deep design implications.
• Removing the features might complicate the software,
consume more resources, and foster more bugs.
1.3 Feature Interactions Bugs
• Feature interactions: providing correct, clear, implementable
and testable feature specifications is not enough.
• Features usually come in groups or related features.
• The features of each group and the interaction of features
within each group are usually well tested.
• The problem is unpredictable interactions between feature
groups or even between individual features.
• For example, your telephone is provided with call holding
and call forwarding. The interactions between these two
features may have bugs.
• Every application has its peculiar set of features and a much
bigger set of unspecified feature interaction potentials and
therefore feature interaction bugs
Specification and Feature Bug Remedies
• Short-Term Support : Specification languages facilitate
formalization of requirements and (partial)* inconsistency and
ambiguity analysis. With formal specifications, partially to fully
automatic test case generation is possible.
• Long-Term Support : Assume that we have a great specification
language and that it can be used to create unambiguous,
complete specifications with unambiguous, complete tests and
consistent test criteria.
Testing techniques for functional Bugs.
• Most functional test techniques- that is those techniques
which are based on a behavioral description of software,
such as transaction flow testing, syntax testing, domain
testing, logic testing and state testing are useful in
testing functional bugs
2.Structural Bugs
• Various categories in Structural Bugs:
1. Control and Sequence Bugs
2. Logic Bugs
3. Processing Bugs
4. Initialization Bugs
5. Data flow Bugs and Anomalie
2.1 Control and Sequence Bugs
• Control and sequence bugs include paths left out, unreachable code,
improper nesting of loops, loop-back or loop-termination criteria
incorrect, missing process steps, duplicated processing, unnecessary
processing, rampaging GOTO’s, and ill-conceived switches.
• One reason for control flow bugs is that this area is amenable to
theoretical treatment.
• Most of the control flow bugs are easily tested and caught in unit
testing.
• Another reason for control flow bugs is that use of old code
especially ALP & COBOL code are dominated by control flow bugs.
• Control and sequence bugs at all levels are caught by testing,
especially structural testing more specifically path testing combined
with a bottom line functional test based on a specification.
2.2 Logic Bugs
• Bugs in logic are related to: Misunderstanding how case
statements and logic operators behave singly and
combinations
• Include non existent cases
• Improper layout of cases “Impossible” cases that are not
impossible a “don’t care” case that matters
• Improper negation of boolean expression
• Improper simplification and combination of cases
Overlap of exclusive cases
• Confusing “exclusive OR” with “inclusive OR” The best
defense against this kind of bugs is a systematic analysis
of cases.
2.3 Processing Bugs
• Processing Bugs include arithmetic bugs, algebraic and
mathematical function evaluation, algorithm selection
and general processing.
• The reasons for Processing Bugs:
• Incorrect conversion from one data representation to
another.
• Improper use of ,<=,>=
• Improper comparison between various formats
• Although these bugs are frequent 12%, they tend to be
caught in good unit testing and also tend to have
localized effects.
2.4 Initialization Bugs
• Initialization bugs are common, both improper and
superfluous initialization occur.
• Typical initialization bugs are:
Forgetting initialize work space, registers
Forgetting initialize data areas before first use or
assuming that they are initialized else where
A bug in the first value of a loop control parameter
Accepting the initial value without a validation check
Initializing to the wrong format, data representation or
type
2.5 Data flow Bugs and Anomalie
Most initialization bugs are special case of data flow
anomalies.
A data flow anomaly occurs when there is a path along
which we expect to do something unreasonable with
data, such as using an uninitialized variable, attempting
to use a variable before it exists, modifying and then not
storing or using the result, or initializing twice without an
intermediate use.
3. Data Bugs
Data bugs include all bugs that arise from the
specification of data objects, their formats, the number
of such objects, and their initial values.
The increase in the proportion of the source statements
devoted to data definition is a direct consequence of two
factors:
1. The dramatic reduction in the cost of main memory and
disc storage.
2. The high cost of creating and testing software
Dynamic Versus Static
• Dynamic data are transitory. Whatever their purpose, they have a
relatively short lifetime, typically the processing time of the
transaction. A storage object may be used to hold dynamic data of
different types, with different formats, attributes, and residues.
• The dynamic data bugs are due to leftover garbage in a shared
resource.
• This can be handled in one of three ways:
I. Cleanup after use by the user
II. Common cleanup by the resource manager
III. No clean up
• Static data are fixed in form and content. They appear in the
source code or database directly or indirectly, for example a
number, a string of characters, or a bit pattern.
• Compile time processing will solve the bugs caused by static data.
4. Coding Bugs
• Coding errors of all kinds can create any of the other
kinds of bugs.
• Syntax errors are generally not important in the scheme
of things if the source language translator has adequate
syntax checking.
• If a program has many syntax errors, then we should
expect many logic and coding bugs.
• The documentation bugs are also called as coding bugs
which may mislead the maintenance programmers.
5. Interface, Integration, and System Bugs
• Various categories of bugs in Interface, Integration, and
System Bugs are:
1. External Interfaces
2. Internal interfaces
3. Hardware Architecture
4. Operating system
5. Software Architecture
6. Control and Sequence Bugs
7. Integration bugs
8. System bugs
6. Test and Test Design Bugs
• Testing: testers have no immunity to bugs. Tests require
complicated scenarios and databases.
• They require code or the equivalent to execute and
consequently they can have bugs.
• Test criteria: if the specification is correct, it is correctly
interpreted and implemented, and a proper test has
been designed; but the criterion by which the software’s
behavior is judged is incorrect or impossible.
Test Design Bugs-Remedies
• The remedies for test bugs are:
1. Test Debugging
2. Test Quality Assurance
3. Test Execution Automation
4. Test Design Automation
