Yesterday, Halloween, I spoke at the monthly KWSQA meeting on automation. A topic that isn’t too too much of a surprise and there wasn’t any really new content. Of course I embellished things with stories, etc. but if you weren’t there…

**[\[Automation\] Trick-or-Treat Style](http://www.slideshare.net/agoucher/automation-trickortreat-style "[Automation] Trick-or-Treat Style")** from **[Adam Goucher](http://www.slideshare.net/agoucher)**
  • Zoom! – Treat (photo credit): First and foremost, the goal of automation is not to find bugs. It is there to allow you, the human, a degree of confidence that you can ignore entire chunks of your application and so allow you to focus your energy on the other parts. But automation also allows you to speed up environment and scenario setup. Or as Chris McMahon once stated on the agile-testing mailing list, to Zoom! through the application.
  • ROI – Trick (photo credit): See the ‘Time Machines’ section of Lightsabers, Time Machines, & Other Automation Heuristics
  • Page Objects – Treat (photo credit): This design pattern can apply to almost any automation framework. The idea is to slice you pages into either a single class, or a group of classes so that you can use OO principles in automation design. This is the best way we currently have for removing the bulk to the maintenance woes that comes with automation. There are lots of examples out there once you know what term to look for.
  • Implicit Waits – Trick (photo credit): Apologies to the non-Canadians for how funny this slide actually is. Like these candies, Implicit Waits seem like a good idea … until you use them. Implicit waits can solve some your flakey automation runs, but the price paid is lazy, inefficient code. Learn exactly what your pages consider ‘synchronized’ and hook onto that. If you are using implicit waits right now, start rolling back the timeout value and as things break replace them with explicit waits. (A nice side effect of explicit waits is that you, the automator, get a more complete model of how the application is structured which will help you in other testing efforts as well.)
  • Use The Source – Treat (photo credit): See the ‘Lightsabers’ section of Lightsabers, Time Machines, & Other Automation Heuristics
  • Same … but Different! – Trick (photo credit): The one downside of doing decks like mine is if you forget what you were thinking when you did it then you are screwed when you present it. As was the case with this slide. Anyhow, I remembered at 1 AM… I loathe the trend of using JS Widgets to represent something that could be expressed as a regular HTML element. DHTMLX*, YUI*, GWT*, DOJO* — SCREW YOU! It looks like a select, but when you go to automate it you find yourself facing a day-long rabbit hole in order get beyond it. You thought I was cranky now, just wait another 10 years where I have to deal with a couple of these every month. Sometimes using something like this adds value to the application, but more often than not it is just designer porn.
  • 3rd Party Crap – Treat (photo credit): Nothing wastes more time in automation than waiting for things to load that are not related to the thing you are actually trying to automation. See Get Rid of 3rd Party Crap for how to remove it programatically. You can also use something like the hosts file hack, but really you should be using feature switches to be able to choose what is enabled or not in a particular environment.
  • Infrastructure – Treat (photo credit): I’m becoming more and more convinced that a lot of the perceived inefficiencies in automation (and testing in general) could be addressed if we could just wrangle our environments under some semblance of control. Hey wait a minute! We can! Using tools like Puppet or Chef. Even though the testing community is having a hard time to digest the notion that all testers should learn programming (at least the basics) I’m going to add to that and say that testers should learn how to do this stuff as well. Or just continue to spin wheels waiting for environments to be setup incorrectly for you by someone else…
  • Infrastructure (photo credit)