Test automation is the perennial "hot topic" for many test managers. The promises of automation are many; however, many test automation initiatives fail to achieve those promises. Shrini Kulkarni explores ten classic reasons why test automation fails. Starting with Number Ten ... having no clear objectives. Often people set off down different, uncoordinated paths. With no objectives, there is no defined direction. At Number Nine ... expecting immediate payback. Test automation requires a substantial investment of resources which is not recovered immediately. At Number Eight ... having no criteria to evaluate the success. Without defined success criteria, no one can really say whether the efforts were successful. At Number Seven ... Join Shrini for the entire Top Ten list and discover how you can avoid these problems.

• Why so many automation efforts fail
• A readiness assessment to begin test automation

You've committed to an agile process that encourages test driven development. That decision has fostered a concerted effort to actively unit test your code. But, you may be wondering about the effectiveness of those tests. Experience shows that while the collective confidence of the development team is increased, defects still manage to raise their ugly heads. Are your tests really covering the code adequately or are big chunks remaining untested? And, are those areas that report coverage really covered with robust tests? Andrew Glover explains what code coverage represents, how to effectively apply it, and how to avoid its pitfalls. Code coverage metrics can give you an unprecedented understanding of how your unit tests may or may not be protecting you from sneaky defects.

All business applications implement business rules. Unfortunately, the rules can be very dynamic due to changes in requirements by external organizations and internal forces. Wise application designers and developers do not imbed the implementation of specific business rules within applications but define, store, and maintain them as data outside the applications that use them. Likewise, wise testers now use a similar approach called business rules-based test automation in which automated test scripts are written against the business rules rather than against the application. This process incorporates technical components such as a robust testing keyword library, a business-friendly user interface, and automated script generators to accelerate the test automation work and cover more business scenarios than with the conventional approach.

Automated GUI tests often fail to find important bugs because testers do not understand or model intricate user behaviors. Real users are not just monkeys banging on keyboards. As they use a system, they may make dozens of instantaneous decisions, all of which result in complex paths through the software code. To create successful automated test cases, testers must learn how to model users' real behaviors. This means test cases cannot be simple, recorded, one-size-fits-all scripts. Jamie Mitchell describes several user behavior patterns that can be adopted to create robust and successful automated tests. One pattern is the 4-step dance, which describes every user GUI interaction: (1) ensure you're at the right place in the screen hierarchy; (2) provide data to the application; (3) trigger the system; and (4) wait for the system to complete its actions.