Effective Software Test Automation presents a hands-on case study with code to create a test tool capable of generating test scripts, data stores and output summary. While the concepts discussed certainly apply to the development of most tools, the code provided is specific to the .Net environment using C# as the development language, and the bulk of the book is dedicated to describing how the tool is created in that environment with full code listings. I would recommend this book to testers and developers who are new to the .Net development environment or those who may have worked in it and want to start considering a tool to generate test scripts.
This book accomplishes two important goals. The first is the step by step creation of the test tool. I implemented the code to create the automated test tool to generate the data store and the test script up through chapter 7 without any problems. It worked as described, and the code, along with its description, for the remainder of the book was well presented. The second significant contribution the book makes is the tour it takes the reader through aspects of the .Net environment. It demonstrates the robust development qualities in .Net. An example of this is the hands-on discussion of the namespace system.Reflection. Further, it provides an insightful guide to referencing the MS Excel Object Library through example as the code dynamically creates a datastore in an Excel worksheet.
The authors also provide an overview on how to use the tool effectively and provide adequate notes on usage context. Towards the latter part of the book they are adamant that testers still need to analyze the requirements and understand the data used to test the application. For instance, testers still need to understand concepts such as boundary value analysis, equivalence partitions and other testing techniques which are more thoroughly addressed in other theoretical texts. It should be noted, that the tool presented by the authors does not guarantee code coverage (i.e. path analysis within a method). Readers will have a better appreciation for the tool if they study some of the classics in testing theory by Glenford Myers, Robert Poston and Paul C. Jorgensen.
The tool itself is certainly useful from the standpoint of regression testing. In other words, once an application is stable in its functionality, the test scripts generated can form a baseline of testing when changes are introduced. The authors do mention XP, but I have to comment as to the effective use of the tool in XP development. In XP, testing is based on test driven development (TDD). In TDD, the test script is written BEFORE the implementation code is ever produced. In TDD (agile development) the test harness is an up front statement of the design stating what the code should do - not what it already does because it hasn't been written yet. Their tool requires the implementation code (actually, the assembly) to be created before it creates the test script. Again, though, there are many development efforts where TDD is not used (the majority actually ) and the tool the authors present provides a good start for analysis of code completed by developers to generate an initial set of scripts when a maintenance environment receives transitioned code. Their observations of the spirit of XP are very accurate. I am only expressing a philosophical concern in the testing arena.
In essence, the tool can have benefits, but like any tool should be used in the proper context. Developers should not assume that any tool can replace human intuition and solid testing techniques.
Overall, I found the book to be well focused and clearly written. I only have two criticisms of the book itself, which is why I would rate it four out of five stars (which for me is a good rating). I think the title or cover should have noted something about .Net (e.g. "A Case Study Using .Net"), even though the authors claim the concepts are generic. The concepts are, but the implementation is not since legacy programming environments do not have support for integrating an XML framework in the code for comments. In my previous life as a UNIX and C developer and considering the cost, I would get very little benefit from the text since the "generic" part is limited after Chapter 2. Second, while the authors provided a high level discussion of the features the tool would provide in the later part of Chapter 2, it would have been helpful had there been illustrations with a brief description of how it would be used earlier. The tool creation was presented piece by piece, and while I was able to follow along with the authors, I found myself immediately skipping ahead to Chapter 7 to get an idea of what the end product would look like. After doing so, I went back to where I left off in Chapter 4 and the rest was fine. It's a small thing actually, but an early picture or two of where the code is taking the reader is helpful.
