Project testing aims at identifying faults in the program and a test is deemed successful only when faults are discovered, writes Dr R Srinivasan

"Care should be taken during the process of fault correction that new mistakes are not introduced"

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 confirm 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 where as 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 organization 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 fault occur not only in coding but anywhere in a software system. If the types of faults occurring in an organization 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 IBM's 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/organization independent and includes all stages of the development cycle, just not coding alone.

( to be continued )

(The author is Chief Technology Officer, Internet Component Management Group, Bangalore and can be contacted at: r.srinivasan@iCMGworld.com)