Two of the main questions that have to be answered in implementing automated software testing are: (1) who performs the automation, and (2) how do they implement it. The answers an organization adopts will dramatically affect the success or failure of the automation effort itself. While there is no single answer to these questions, there are a number of strategies, some of which work well. Understanding what the common strategies are for implementing automation can assist you in choosing the right one for your organization, and in understanding the benefits, costs and risks of the specific strategy you select.

The Record and Playback strategy is by far the most common one demonstrated by vendors and pitched by tools sales representatives to managers. It is also common to see this strategy abandoned within a month or two. The Record and Playback strategy is to use the tool as though you are someone actually executing a test case, then play it back whenever needed without making any changes to the test case. Unfortunately, the next release that comes out will break large numbers of these test cases when changes to either the user interface or the application result in script failures. This is where the Record and Playback strategy falls apart. It takes longer to record (and re-record, every time the application being tested changes) a test case then it does to run through it manually. There are other problems with a pure Record and Playback strategy that make it impossible to scale test cases done in this way to any significant numbers without constantly having to maintain -- actually, more like change -- the code.

Now let me add a caveat: Just because the Record and Playback strategy does not work does not mean that the recorders themselves are useless. Often recorders are useful in the initial development of test cases, supplemented by scripting. This variation -- more like Record and Modify -- may be a good way to initially develop test cases. So the recorders are useful, though they cannot do the whole job. That is, if what you want is maintainable, reusable tests.

If managers persevere with automation after this first failure, they usually do so using one (or both) of the next two strategies: Tester Automation or The Automation Group. Tester Automation involves giving the automation responsibility to a group of technical testers. Tester Automation can work well, but only if you already have a very technical team of testers. I have seen this strategy work very effectively in testing teams where the testers already had good programming skills when the test automation effort began.