Book: Effective Software Test Automation

During my time in the quality assurance department I have read through several books, but so far I have only found two books that I recommend the other QA staff reads. The first book is Lessons Learned in Software testing. The second book is this one, Effective Software Test Automation: Developing an Automated Software Testing Tool.

I came across this book a few months ago while shopping at Borders. When I picked it up I wasn’t quite sure what to expect but it sounded like an interesting read because I had done quite a bit with reflection while testing our .NET components, and I had been looking for ways to do more test automation. I decided to take a few days to read through the book and built the project it walks the reader through. By the time I had finished reading the book I had already order more copies for my co-workers because it had some very interesting ideas I thought would be helpful to all team members.

With all the previous .NET components I had tested I had used reflection to semi-automate tests and I was pretty familiar with how this worked, so this aspect of the book was familiar because I had been using similar methods. However, the book introduced me to two other concepts I had never thought about. The first idea was using reflection to export the class member information to an excel workbook and using excel as a data store to later generate scripts from. The second idea was using codedom to automatically generate test scripts (in VB.NET or C#) from the data stores. 

The concept the book shows is to use reflection to gather all the member information of a class and save that information to a data store where it can be modifed to setup particular test cases with specific data. Once the data store is created the project uses codedom to read through the data store and automatically generate a VS.NET project that will test the different members.

The project the book has the reader create is very interesting, but I found it really didn’t work too well for our components. The ideas were there, though, and I was able to construct a rough project that would automatically create NUnit tests from the class’ members.  I was able to take what the book had started and modify it to automatically export to excel a range of test data for most common member types, as well as set it up to allow me to enter specific information into the excel file to create my own objects that are not easily auto-generated in code. From there I was able to use codedom to create a NUnit test project that could be automatically run.

The project is by no means a cure all for generating test automatically, but you can do a very good job of generating a lot of good code quickly. The results are more for unit style tests where you are verifying the properties are being set correctly, but it also creates a framework for method testing that a person can easily add code to when they are ready. If you are working in an environment where the QA team needs to test every property and method this is a good start. It was really the ideas in the book that impressed me because they will be useful in future testing efforts.

A word of warning though, the book did have some typos and problems with the code samples so you will probably need to download the code that goes with the book. I also found the text in the book really oversimplifies the project the book walks the reader through.

posted @ Sunday, June 27, 2004 4:53 PM

Print
«September»
SunMonTueWedThuFriSat
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567