|
Project
testing aims at identifying faults in the program and a test is
deemed successful only when faults are discovered, writes Dr R Srinivasan
Another
important activity as part of the software development cycle is
testing. In the development of any product, testing
at every stage is a very important activity so that the final product,
to be delivered to the customer, will be extremely reliable. In
the case of the development of software system, testing is all the
more important because the system will deal with a large number
of states, sometimes with complex algorithms and functions to be
implemented. In addition to these from the technical side, we also
have the human aspects. Different modules are developed by different
groups, which calls for uniformity with perfect understanding and
communication with each other. If the customer himself is uncertain
of what exactly is needed, the entire development will get into
a vicious circle. Thus the presence of faults in a software product
is a function of not just the software by itself, but also of complexity
introduced due to the number of people involved in the development
and expectations of the customer/user. If proper care is not taken,
the faults will lead to software failure. Failure means that the
developed software does not yield what the requirements dictate
and hence testing at each stage is not only a necessary requirement
but also essential.
It
should be borne in mind that testing does not mean to
just go through the software code and say that everything is fine;
to prove the correctness of the program is exactly the reverse of
testing in software development terminology. Test plan in a project
aims at identifying faults in the program and so a test is deemed
successful only when faults are discovered. Care should be taken
that during the process of fault correction new ones are not introduced.
Shari
Fleeger in her book on, Software Engineering - Theory and
Practice, classifies the types of faults that normally occur
in software development into 11 different categories as follows:
1). Algorithmic fault is the one that occurs when a unit of the
software does not produce an output corresponding to the given input
under the designated algorithm, 2). Syntax faults are due to the
nonconformity of programming language, 3). Computation and Precision
faults occur when the calculated result using the chosen formula
does not conform to the expected accuracy or precision, 4). Incomplete
or incorrect documentation will lead to Documentation fault, particularly
when another group of people try to use the document, 5). Stress
or Overload fault happens when data structures are filled past their
specific capacity whereas the system characteristics are designed
to handle no more than a maximum load planned under the requirements,
6). Capacity or Boundary faults occur when the system produces an
unacceptable performance because the system activity may reach its
specified limit due to overload, 7). Timing or Co-ordination faults
are typical of real time systems when the programming and coding
are not commensurate to meet the co-ordination of several concurrent
processes or when the processes have to be executed in a carefully
defined sequence, 8). When the developed system does not perform
at the speed specified under the stipulated requirements, it will
lead to Throughput or Performance fault, 9). If the system does
not recover to the expected performance even after a fault is detected
and corrected, we face the situation of a Recovery fault, 10). Faults
also occur when the vendor-supplied hardware/software does not meet
the promised operating conditions and procedures and 11). Standards
and Procedure faults occur when a team member does not follow the
standards deployed by the organisation which will lead to the problem
of other members having to understand the logic employed or to find
the data description needed for solving a problem.
It
is a fact that faults occur not only in coding but anywhere in a
software system. If the types of faults occurring in an organisation
are documented, it will help in the case of future products, to
predict and expect what types of faults are likely to happen. By
following a statistical fault modelling and causal analysis, it
will be very helpful to understand the number and distribution of
faults. The typical example is that of IBMs Orthogonal Defect
Classification when the defect prevention process seeks and documents
the root cause of every problem that occurs. This type of classification
scheme is product/organisation independent and includes all stages
of the development cycle, just not coding alone.
-
|