Welcome to Automation By Design, a new column about software test automation for testers and other software development professionals. The automation of testing is an emerging field that can be very rewarding to both companies and individuals alike. Like many other new technologies, however, there is more than meets the eye for the uninitiated; success is not automatically guaranteed simply because your organization has bought a tool. Full Article

Last issue, we discussed reasons why test automation projects often fail. So how do we ensure success? The bad news is that there is no magic formulae for success; it is conceivable that your organization may do everything right and still fail. Software development (and test automation is most definitely software development) just works that way. The good news is that you can enhance your chances of success by attention to detail, good processes, and hard work. Full Article

In the last issue, I put together an organizational blooper film: exposing a hypothetical automation attempt at a fictional company in which every step taken destined the project to failure. In reality, the example was a composite of many failed automation projects that I have seen or been party to. Full Article

In the last issue, we discussed designing test automation that can be maintained more cost effectively than recording-only scripts. The software engineering methodology we are going to adopt is called functional decomposition. We will use the test tool language directly to build an infrastructure containing sub-routines that directly execute tasks in the application(s) we are testing. The functions we build will be analogous to building blocks or Legos; the scripts we execute will be largely made up of sets of Legos combined in different ways. Although the examples are written in Mercury Interactive WinRunner, this approach works with any of the major test tools. Full Article

In our last column, we talked about the need for designing our automation scripts in such a way that they would be effective, maintainable and affordable. There are several different automating methodologies available to the automator; the one we have chosen to illustrate this time is called functional decomposition. Full Article

So I'm sitting here in the Minneapolis airport, waiting for a jet plane to take me to yet another place to talk about how to's: how to solve this test automation problem using that technique on this platform with this operating system, yadda yadda yadda. It struck me that I am always talking about how and rarely about why. Why doesn?t this automation technique work as advertised? Why doesn't record / playback ever work (well, so very rarely that it is hardly worth talking about.) This column is about test automation, and mostly we talk about how to make it work, how to get the greatest return on the investment we make. Today we are going to talk about why we need to do what we do. Rather than looking at the trees as we have in the last several columns, lets look at the forest. Full Article

In my last column (June 2001), I advanced the hypothesis that one of the main reasons the Record / Playback (R/P) methodology of test automation usually fails to achieve set testing goals is that the paradigm does not sufficiently model real world testing. I also laid out several behavioral models including the manual testing model (how do manual testers actually plan and run tests) and the event-driven architecture model (how do we actually interact with a GUI-based operating system.) Full Article

The question from the client was simple, almost deceptively so. "Why should we automate our testing?" Hidden inside that query, of course, were several other questions, "Why should my company spend tens of thousands of dollars, buying software, training automators, creating scripts, etc.? What will we get out of it?" Full Article

Henry Ford invented the automobile. Just ask any elementary school student who has suffered through Miss Waxman's twisted idea of history class. Benjamin Franklin invented electricity while flying a kite, Marconi invented the wireless radio, and Don Ameche invented the telephone.
History is rife with examples of people getting credit for the invention of an object, technique or process; sometimes even justifiably. Full Article

OK, I'll admit it. I think everyone should be able to cook a gourmet dinner, kill a bear, fly an airplane, and program test automation. Unfortunately, this is yet another case of where our school system has failed us! Specialization appears to be the bane of civilization. Full Article