Editorial

The two articles in this volume of STVR represent a polarisation since they examine respectively inspection and testing. If you are going to be polite you say that the two approaches are complementary, otherwise you cite the mounting body of evidence that inspections far outperform testing in terms of what Tom DeMarco might call ‘bugs per buck’. Some of this evidence is presented by Macdonald et al. in ‘Applying inspection to object-oriented code’ but the motivation for their paper is that we have yet to establish whether or not this evidence holds good for the object-oriented paradigm. In the absence of any empirical studies, the Empirical Foundations of Computer Science team at Strathclyde University offer us an analysis of what object-orientation and its use can tell us. For example, long chains of inheritance may militate against effective code inspection. In fact, this may not be an issue in practice where inheritance seems to be mostly absent: this was the result of recent studies by Bieman and Zhao (1995) and Stiglic et al. (1995) and was the consensus at the 1996 Software Metrics workshop at Bournemouth University in the U.K. which I attended in May. Dynamic aspects of object-orientation are probably more likely to sabotage the efforts of inspection teams; in particular, Macdonald et al. devote some time to looking at polymorphism. As they point out, it is worth drawing upon the experience of testers of object-oriented code, where, for example, Perry and Kaiser (1990) long ago identified polymorphism as undermining some of the basic assumptions. The potential for inspectiondefying code can probably only be defused by disciplined programming using techniques, which the paper identifies, such as the Law of Demeter. Tool support may be some help and this is also covered by the paper, although an article which appeared too recently for consideration deserves mention: Pintado’s ‘affinity browser’ (Pintado, 1995) is aimed at many of the same problems which Macdonald et al. have enumerated so clearly for us. There is not, on the face of it, any confrontation between inspection and selective regression testing: here we are assuming that some testing has already been carried out and that changes to the code necessitate a re-run of the test data. The problem of selective regression testing is to avoid retesting those parts of the code which are unrelated to the modified code. Still the approach adopted by Gupta et al. in ‘Program slicing-based regression testing techniques’ does suggest a link with inspections: program slicing was originally devised by Weiser as a model of the cognitive process involved in maintenance. Thus slicing mimics the efforts of the maintenance engineer to trace data flow forwards and backwards from a point of change. Gupta et al. exploit these traces to generate precisely the definition-use associations which need to be retested after the change is made. Their paper was originally presented at the 1992 International Conference on Software Maintenance but has been considerably enhanced and updated with more examples and explanation and a quarter of the references being new. As with inspections, we would like to know whether slicing-based techniques are transferable to the object-oriented domain. After all, in an object-oriented program, data flow will be limited in the first place by what may be very small methods, and in the second place by the class boundary. As with code inspection not much research seems to have been done on this, although there is some recent work at the University of