Automation

It's May 15, 2010, and you're in a triage meeting reviewing the testing status and bugs in your telemedical software. The system uses real-time voice, video, graphics, and an expert knowledge base to support expert medical procedures in remote locations. As the test manager, you're using trace diagrams, deployment diagrams, runtime fault injection, coverage views, test patterns, built-in self test, and other modern, agile techniques to review the bugs, diagnose faults, assign priorities, and update your test plans. Sam Guckenheimer contrasts the methods available to you in 2010 versus the techniques you used years ago when you were starting out as a test manager.

As Web applications move from static content to dynamic transactions, the risk of failure increases while cycle time collapses. Although automation is the ideal solution for this combination, those who've ventured into automated Web testing have discovered a whole new world of unexpected challenges. For instance, dynamic page layouts and content frustrate test automation requirements for predictability and repeatability, while the lack of meaningful-let along consistent-object names further complicates consistent execution. Ultimately, this leads to excessive maintenance and lower productivity. This presentation shows you how to identify the potential issues that come with automated Web testing, then offers ways for you to incorporate site and test development strategies to overcome them.

Implementing test automation without following best practices and tracking your ROI is a prescription for failure. Still, many companies have done so seeking the elusive promise of automated testing: more thorough testing done faster, with less error, at a substantially lower cost. However, fewer than fifty percent of these companies realize any real success from these efforts. And even fewer have generated any substantial ROI from their automated testing initiatives. This presentation takes an in-depth look at the specific pitfalls companies encounter when implementing automated functional testing, and offers proven best practices to avoid them and guarantee long-term success.

Most test tools come bundled with vendor-specific scripting languages that I call vendorscripts. They are hard to learn, weakly implemented, and most importantly, they discourage collaboration between testers and developers. Testers deserve full-featured, standardized languages for their test development. Here’s why.