Software Test Automation: Effective Use of Test Execution Tools

Citation

Hutton, D.M. (2000), "Software Test Automation: Effective Use of Test Execution Tools", Kybernetes, Vol. 29 No. 3, pp. 392-398. https://doi.org/10.1108/k.2000.29.3.392.5

Testing software remains, after so many decades, both a difficult and controversial process. These two books contribute to making software testing more efficient and transparent. The first book of the two is concerned with improving the testing process and presents a practical stage‐by‐stage introduction to its procedures. Whether this approach is the right one is a matter for those organisations and institutions convinced of its merits. For many software houses the very use of what is described as a “structured approach” to testing will indeed be a novelty. There is still an air of the “amateur” about much of software that is written and distributed. One is amazed that in practice it works, apparently, so well. When one considers that it is often produced by a team of programmers who may or may not be properly supervised, with each member of the team producing a section that it is hoped will integrate successfully with the efforts of team colleagues, that it works is indeed a miracle. Testing it, however, can be a nightmare process. Obviously, the whole process has to be a fully integrated planned exercise and use made of any tools available. The model produced in this book by Koomen and Pol is called the Test Process Improvement (TPI) model and it aims at providing a structural framework. This, the authors are at pains to point out, can be applied to an existing test procedure or alternatively be used as the basis of an entirely new process. The method advocated is both practical and certainly step‐by‐step and many organisations could well benefit from its structured format. Most software houses would have a problem with it. Having invested so much in their current processes which do, after a fashion, produce the software goods, change would not come easily. The writers are, however, good advocates for TPI and many readers will gain from this exposition.

The second book on software testing is written by Fewster and Graham and gives yet another view of testing software. With the word “practical” and “automated” in the title it suggests a new and exciting approach can be taken to testing. While my own view is that software production should be the subject in question, with testing but an integral part of the whole process, this book has a place in the chain of activities that finally produce “good” software. The whole process should, of course, be automated, and software engineers should be concerned that after some 40 years (probably more if we include Babbage’s experimental work) machines cannot play a much greater part in producing their own. To test software using some sort of manual “hit‐or‐miss” piece of program is rather like putting the proverbial “horse” before the “cart”. Anyone who has had the task of certifying software after it has been produced knows that it is a daunting job. In so many safety‐critical scenarios the task is almost impossible. This is why we all dread the arrival of yet another “patch” or so‐called up‐dated issue or version. Many professional software engineers employed to test software are still placed in the position of having to carry out the whole process by simply employing manual tests and analysing the results. Any book, therefore, that can introduce a process of automation into testing has to be welcome. An introduction to the principles of such testing is given by the authors, as well as some good advice on selecting appropriate tools. They also suggest ways in which the chosen tools can best be used and also the methods they recommend to increase the automation of the process. Both books are worth reading, if only to provide the readers with a little of the authors’ enthusiasm for change in a process that can only at the beginning of the twenty‐first century be described as archaic.