Seretta Gamba has more than thirty years’ experience in software development and testing. As test manager at Steria Mummert ISS GmbH, Seretta was charged with improving their test automation process. After studying other strategies, she developed command-driven testing and a supporting framework. Seretta presented an enhancement to the framework that enabled the test automation team to “harvest” test case information by supporting manual testing. A description of this experience became a chapter in Experiences of Test Automation by Dorothy Graham and Mark Fewster.
After working to develop the test automation patterns used by experienced practitioners to solve common test automation issues, Seretta Gamba started to consider what can ruin a test automation effort instead. Here she shares two sure-fire methods that can destroy your test automation. Steer clear of these examples!
Command-driven testing has proven to be a good way to implement pattern tool independence. The main advantage is that you just have to develop the commands in the script language of the tool. To change tools, you only have to rewrite the keyword commands in the script language of the new tool.
When doctors diagnose new patients, they start by asking general questions. And depending on the answers, they ask more specific questions. The same can be done with patterns! Asking about the condition of a test automation effort can lead to the specific issue that’s ailing the project—and a cure.