Implementing Automated Software Testing

This book “Implementing Automated Software Testing”, Elfriede Dustin, Thom Garrett and Bernie Gauf presents a comprehensive treatment of the domain of software testing automation. The first part defines and describes test automation, proposing a business case for automation and discussing the pitfalls that should be avoided.

The second part is a roadmap for test automation. It gives six keys for software testing automation payoff:
1. Know your requirements
2. Develop a strategy
3. Test your tools
4. Track progress and adjust
5. Implement the process
6. Put the right people in the process.
Four appendixes complete the book. They provide a process checklist, explain how automation applies to various testing types, discuss tools evaluation and give a case study.

The fact that the authors have worked with the Defense industry might have affected the way the book was conceived and written: with structure and rigor. The discussions, references and tools suggestions apply however to every software testing situation and not only to organization that are strongly process oriented. The aim of the book is to be a guide that can help to implement successfully automated software testing and it certainly achieves its objective.

Reference: “Implementing Automated Software Testing”, Elfriede Dustin, Thom Garrett & Bernie Gauf, Addison Wesley.

Quotes

Although much attention is generally paid to the cost of software development, and much excitement is generated from technologies that offer development productivity improvement, the cost and productivity of software testing are often ignored or just accepted as “this is what it costs and how long it takes.” This is ironic in that the cost and time of software testing are often comparable to the time and cost of developing the software.

How much of the test program can be automated? Not all the tests for a project can or should be automated. The best candidates for AST are those that are repeated the most often and are the most labor-intensive. Tests that are run only one time or infrequently will not be high-payoff tests to automate, unless the given context warrants for automation, for example, if the test is difficult or cost-time-prohibitive to run manually. Further, test cases that change with each delivery are also not likely to be high-payoff to automate if the AST needs to change each time.