mate some of the tasks which would call on their own subordinates. be carried out by reviewers inspections and walk throughs. They are With this architecture a 'top-down' approach can be used. Testing usually applied to program code, and look for violations of stand- begins with the top level module, supported not by its subordinate ards or of good practice. An example is the Unix tool 'lint' for units but by dummy modules known as 'stubs'. The stubs simply analysis of code in the programming language C. provide to the module under test the data it requires. The converse, Little support exists for the auditing of specifications, designs and 'bottom-up' approach starts with the lowest level modules. The other textual outputs of the system development process. Usually all tester either provides simple 'drivers' to control the unit under test, that can be applied is a spelling checker. As the representation of or employs a tool harness, which is a general purpose test aid able Testing procedures 25/15 to feed data into the unit end to collect results. More comprehensive which it is meant to provide. For each item in the specification harnesses may also be able to compare the results with the expected it should be possible to show one or more tests which examine outcome of the test automatically. that item. Testing approaches using equivalence classes and Usually unit testing proceeds with a harness in combination with boundary values mentioned above are forms of function testing. stubs and drivers. Volume testing and stress testing. Individual unit tests tend to Software systems need not have this strict hierarchy. Telecom- be small. However, some faults relate to an inability to handle munications systems frequently make use of co-operating processes large volumes of data; queues, buffers or work files may over- and of object oriented design, and here units need not be subordinate flow. Volume testing is simply subjecting the unit to large to each other in a strict sense. However, testing can still be carried quant