FAULT TAXONOMY

Two main classes of faults:

• Service-related and structure related faults.
• Service-related faults can be syntactic,
semantic, or non-functional.
• Structure-related faults, i.e., faults related to
the structure of the system can derive from
faulting connectors, the infrastructure, or the
topology
 Syntactic Faults
• The syntax of interactions defines the structure of the
requests. Necessary condition to serve a request is that both
the requesting and the serving components agree on the
syntactic form of interaction.
• Agreement on the syntax is not enough to assert correctness
of the interaction; components need to agree on the semantic
and the protocol as well.
• In general, compilers assure the syntactic compatibility
during the compilation phase, but if units are compiled
separately and then combined at deployment time or runtime
this check cannot be performed.
• Often assumptions are made by constraining the interfaces
implemented by other components, but in the final system
these assumptions can be violated.
 Syntactic Faults
• This could happen simply because developers may be
too optimistic with their assumptions, or because a
system update changes the interface.
• Syntactic interface faults take several forms and can
be the cause of different failures depending on both
the used component framework and binding
mechanism.
• Class c = Class.forName("Car");
• InterfaceCar vehicle = (Car)c.newInstance();
• System.out.println(vehicle.capacityValue());
• A sample code that can fail when a component tries to
bind to another component at startup.
 Syntactic Faults
• If the interface Interface Car does not match the
interface implemented in Car, the second
assignment cannot be executed.
• This type of syntax errors occurs frequently
after updating the system, e.g., by updating a
component.
• In other component frameworks, such as
CORBA, the failure may be quite different, in
fact the run-time binding mechanism works
properly only if the searched and the retrieved
interfaces match.
 Semantical Faults
• This fault consists of a violation of explicit or implicit
assumptions on the component behavior.
• The behavior can be specified with different formalism, e.g.,
with natural language or logic.
• Differently from syntactic faults that cause the interruption of the
interaction and, in absence of suitable exception handlers, the
system crash, semantic faults lead to more subtle consequences.
• Semantic faults do not necessarily manifest with the
impossibility of interacting but may result in wrong results that
manifest much later with a failure of another component.
• There are several causes of semantic faults, e.g., wrong
implementation or misbehaving execution flow.
• The compositional approach of the component-based systems
increases the probability of semantic fault.
 Semantical Faults
• Single components may have several dependencies that are
stimulated to correctly perform their tasks, but the component
developers may not know the identity of the components that
will fulfill the request.
• In the same way, the component that will be used to satisfy a
dependency may not be aware of this fact until deployment.
• Correctness of the interaction depends on the syntactic and
semantic agreement of components.
• Several possible semantical faults: misunderstood behavior
fault, misunderstood parameter fault, misunderstood event
generation fault and misunderstood interaction protocol fault.
• A misunderstood behavior fault is the case of a component that
requests a service of another component, expecting a service
different from the provided one. A simple example is the case
of a component
 Non-Functional Faults
• Component-based system must satisfy both functional and non-functional
requirements.
• Often non-functional requirements propagates among components.
• This is the case, for example, of a component A that must produce a result
within x seconds and needs a data from a component B to complete the
computation.
• Often, we do not have explicit information about non-functional properties
of a component, because they are difficult to be formalized.
• Thus, guaranteeing non-functional properties in component-based systems
is particularly hard.
• Scenario where components negotiate the quality of the service before
interacting, further complicate this framework.
• The main kinds of non-functional requirements concern interfaces (e.g.,
User-friendless and usability), performances (e.g., time and memory),
quality of service (e.g., reliability), process (e.g., standard to produce high
quality components), and costs (e.g., bound on the costs). Here, we focus
on performances and quality of service.
 Non-Functional Faults
• In both cases the property of the system is affected by the
performance and the quality of service of its components.
• In the case of performance, the dependencies are
straightforward. In the case of quality of service, the situation
can be very complex: a low-quality component may result in the
impossibility of guaranteeing a required quality of service for the
whole system.
• The interactions among components can be more subtle in the
case of a machine that hosts more than one component, for
example because two running components influences each other
(simply because they share the CPU), or even the component
framework can affect a single component, for example in the
case the component framework broadcasts an event while a
component is performing a computation the CPU could not serve
the component efficiently.
 Faulty Connectors
• Components are linked by connectors, which can be
faulty.
• A faulty connector may include a mismatching
protocol fault or an incompatible data model
• Mismatching protocol faults derive from the absence
of agreement on the used protocol.
• This case must not be confused with the component
level protocol , connector protocols are used to
exchange messages in a single interaction, e.g.,
callback, while component protocol defines
admissible sequence of invocation that can be issued
to a components.
 Faults on the Infrastructure
• The component execution and deployment is supported
by the component infrastructure, if any, and by the
overall underlying system.
• Each component makes some assumptions about the
nature, the available services and the structure of the
system, but for the independent development hypothesis,
it is not possible to predict the assumptions made by the
other component.
• When a component-based system is developed, these
assumptions may generate conflicts.
• Two components that unconsciously interact via the
infrastructure are a potential source of failures.
•
 Faults on the Infrastructure
• Problems of this type may have critical
consequences, but manifest very rarely, and are thus
difficult to diagnostic and remove.
• For example, two components may be in conflict
because they use two different versions of the same
dynamic library or they could interact through
services of the operating system, e.g., the registry, or
by accessing the same file, or by using the same
service, or by sharing the disk.
• These interactions are difficult to be located and
usually non mentioned in the set of dependencies,
and even worse, they rarely manifest with a failure.
 Other Faults
• Component based systems can present faults related to
multi threading.
• Traditional techniques address these faults using global
knowledge about the system.
• Components are heterogeneous units, and we integrate
components developed with different programming
languages.
• In some cases, this integration can lead to subtle faults.
For example, C++arrays begin with index 0, while
Visual Basic arrays begin with index 1, so components
developed with these two languages may fail if they
use an index of an element as the argument of a service
 Error Taxonomy
• Error is a variance of the actual result from the expected
result.
• Errors are a category of software bugs.
• Errors can be introduced as result of incomplete or
inaccurate requirements or due to human data entry
problems.
Common Categories of Software Errors:
Functionality Errors:
• Functionality is a way the software is intended to behave. 
• Software has a functionality error if something that you
expect it to do is hard, awkward, confusing, or impossible.
 Error Taxonomy
Communication Errors
• These errors occur in communication from
software to end-user.
•  Anything that the end user needs to know in
order to use the software should be made
available on screen.
• Few examples of communication errors are No
Help instructions/menu provided, features that
are part of the release but are not documented in
the help menu, a button named ‘Save’ should
not erase a file etc.
 Error Taxonomy
Missing command errors:
• This happens to occur when an expected
command is missing.
Syntactic Error:
• Syntactic errors are misspelled words or
grammatically incorrect sentences and are very
evident while testing software GUI.
• These errors are NOT referring to syntax errors in
code.
• The compiler will warn the developer about any
syntax errors that occur in the code
 Error Taxonomy
Error handling errors:
• Any errors that occur while the user is interacting with the software
needs to be handled in a clear and meaningful manner.
Calculation Errors
• Bad logic
• Incorrect formulae
• Data type mismatch
• Coding errors
• Function call issues , etc.
• In 1999, NASA lost its Mars climate orbiter because one of the
subcontractors NASA employed had used English units instead of
the intended metric system, which caused the orbiter’s thrusters to
work incorrectly.
• Due to this bug, the orbiter crashed almost immediately when it
arrived at Mars.
 Error Taxonomy
Control flow errors:
• The control flow of a software describes what it will do
next and on what condition.
• For example, consider a system where user has to fill in a
form and the options available to user are: Save, Save and
Close, and Cancel. If a user clicks on ‘Save and Close’
button, the user information in the form should be saved
and the form should close.
• If clicking on the button does not close the form, then it is a
control flow error.
• References:
• http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.5
9.5438&rep=rep1&type=pdf
• https://www.softwaretestinghelp.com/types-of-software-err
Faults classified on severity
 VERIFICATION METHODS
• The objective of any verification method is to
review the documents with the purpose of
finding faults.
• Many methods are commonly used in practice
like peer reviews, walkthroughs, inspections,
etc.
• Verification helps in prevention of potential
faults, which may lead to failure of software.
 Peer Reviews
• Any type of testing (verification or validation), even adhoc and
undisciplined, is better than no testing if it is carried out by person(s) other
than the developers / writers of the document with the purpose of finding
faults.
• This is the simplest way of reviewing the documents / programs to find out
faults during verification. We give the document(s) / program(s) to
someone else and ask to review the document(s) / program(s).
• We expect views about the quality of the document(s) and also expect to
find faults. This type of informal activity may give very good results
without spending any significant resources.
• Many studies have shown the importance of peer review due to its
efficiency and significance. Our thrust should be to find faults in the
document(s) / program(s) and not in the persons who have developed
them.
 Peer Reviews
• The activities involved may be SRS document
verification, SDD verification and program
verification.
• The reviewer may prepare a report of
observations and findings or may inform
verbally during discussions
• This is an informal activity to be carried out by
peers and may be very effective if reviewers
have domain knowledge, good programming
skills and proper involvement.
 Walkthroughs
• Walkthroughs are more formal and systematic than peer reviews. In a
walkthrough, the author of the document presents the document to a
small group of two to seven persons.
• Participants are not expected to prepare anything.
• Only the presenter, who is the author, prepares for the meeting.
• The document(s) is / are distributed to all participants. During the
meeting, the author introduces the material in order to make them
familiar with it.
• All participants are free to ask questions.
• All participants may write their observations on any display mechanism
like boards, sheets, projection systems, etc. so that every one may see
and give views.
• After the review, the author writes a report about findings and any
faults pointed out in the meeting.
 Walkthroughs
• The disadvantages of this system are the non-
preparation of participants and incompleteness of the
document(s) presented by the author(s).
• The author may hide some critical areas and
unnecessarily emphasize on some specific areas of
his / her interest.
• The participants may not be able to ask many
penetrating questions.
• Walkthroughs may help us to find potential faults and
may also be used for sharing the documents with
others.
 Incident
• When a failure occurs, it may or may not be readily
apparent to the user ,tester or customer.
• An incident is a symptom associated with a failure that
alerts the user to the occurrence of a failure.
• An incident, in the context of information technology, is
an event that is not part of normal operations that disrupts
operational processes. An incident may involve the failure
of a feature or service that should have been delivered or
some other type of operation failure. 
• Security incidents are events that indicate that an
organization's systems or data may have been
compromised
 Incident
• Can be defined in simple words as an event
encountered during testing that requires review.
• Incident is an unplanned interruption.
• When the operational status of any activity turns
from working to failed and causes the system to
behave in an unplanned manner it is an incident.
• A problem can cause more than one incidents
which are to be resolved, preferably as soon as
possible.
 Inspection
• Many names are used for this verification method like formal
reviews, technical reviews, inspections, formal technical reviews,
etc.
• This is the most structured and most formal type of verification
method and is commonly known as inspections.
• These are different from peer reviews and walkthroughs.
• The presenter is not the author but some other person who
prepares and understands the document being presented.
• This forces that person to learn and review that document prior to
the meeting.
• The document(s) is / are distributed to all participants in advance in
order to give them sufficient time for preparation.
• Rules for such meetings are fixed and communicated to all
participants.
 Inspection
• A team of three to six participants are constituted which is led by an
impartial moderator.
• A presenter and a recorder are also added to this team to assure that the
rules are followed and views are documented properly.
• Every person in the group participates openly, actively and follows the rules
about how such a review is to be conducted.
• Everyone may get time to express their views, potential faults and
• critical areas.
• Important points are displayed by some display mechanism so that
everyone can see them.
• The moderator, preferably a senior person, conducts such meetings and
respects everyone’s views.
• The idea is not to criticize anyone but to understand their views in order to
• improve the quality of the document being presented.
• Sometimes a checklist is also used to review the document.
 Inspection
• After the meeting, a report is prepared by the
moderator and circulated to all participants.
• They may give their views again, if any, or
discuss with the moderator.
• A final report is prepared after incorporating
necessary suggestions by the moderator.
• Inspections are very effective to find potential
faults and problems in the document like SRS,
SDD, source code, etc.
 Inspection
• Critical inspections always help find many
faults and improve these documents, and
prevent the propagation of a fault from one
phase to another phase of the software
development life cycle.