Michael Bolton lit up one of the memes of Agile 2009 last week with his Testing vs. Checking idea. In essence

Checking is something that we do with the motivation of confirming existing beliefs
and
Testing is something that we do with the motivation of finding new information

Parallel to this is a discussion on a mailing list about how companies buy functional test tools (QTP, Selenium, etc.) but don’t use them in which it has been uttered something along the lines of ‘to write tests is to program, to program is to think like a developer, and you can’t think like a developer and be a good tester’.

Bunk.

Automation is a tool to be wielded in such a manner that helps you achieve whatever goal you are striving for. I’m quite convinced that if you don’t know how to code in the next 5 years then you your career in test is artificially limited.

To apply Michael’s new terminology to automation, I see there are three roles it can play.

  1. Checking – This is classical test automation. When I go to this page there are these buttons and they background is that horrible green we use.
  2. Testing – We’re up into the realm commonly referred to as Model Based Testing. You teach the automation setup about the rules of the system and then you turn it on. It will naturally find its way through the system and explore its nooks and crannies. This Exploration provides Information.
  3. Helpers – These are scripts which automate boring, repetitive tasks which let you get to the good part quicker. Perhaps you need to test something 20 screens into your application, and requires some setup. Run the script and in 20 seconds you can start your manual testing.

A successful automation effort needs to have all three of these. The proportion of each will of course vary from company to company (and likely product to product within companies) but you can’t call yourself successful in automation without some of each.