say, 1988). presentation of information about the behaviour of a system as it moves towards the point of failure, assuming that the failure is repeatable. The values of variables may be displayed at selected points in the execution, and the path taken through the code may be 25.7.3 Testing systems traced. The approaches to testing summarised above tend to apply to components of a system. However, a system at one level is often a 25.7.4.2 A process for debugging component of a system at a higher level, and SO the division between system and component is to a degree arbitrary. Nevertheless, there The usual steps taken are first to check that the failure can be are some issues in testing which relate to the testing of systems as reproduced and then to find the most simple case available which aggregations of components, rather than to the components them- exhibits the failure. Then an attempt is made to localise the fault, selves. focusing attention on some subset of the system. During this simpli- fication and localisation a number of hypotheses will be developed, and some rejected. The likely hypotheses, if there are any, then need 25.7.3.1 Integration testing to be checked against all the symptoms of the failure. If a hypothesis checks out, a correction may be devised, installed and retested Integration testing looks to see that the (partial) system built from a (Araki, 1991 collection of components behaves as expected. This testing will An isolated fault may represent a class of faults which exist include functional testing of the integrated system, but it focuses on elsewhere in the system, SO having corrected the first instance of the the interfaces between components. problem consideration should be given to the possible presence of At this stage more importance tends to be given to be non-func- similar faults elsewhere. tional attributes of the system, such as performance and usability. At earlier stages of development these attributes may need to be exam- ined by modelling (q.v.). 25.7.4.3 Stability Softwar