How to teach non-tech savy testers to automate (part 1)

or "Make the testers more effective"

Watch out here, you are about to be critted by a wall of text... and as usual the troll expects all to forgive him his mistakes, especially all the typos!

Make the testers more effective..

I have gone through this a couple of times, and there have been some good articles on related subjects. But I can't seem to find them when I need to. In short I usually find me in the position of advocating that we need to make a testers time more effective. So we need to teach testers to automate their test. Now some of them are from a programmer background, some have education in systems development on so on and so forth.
But there is always some there that do not either have the technical background or just haven't had the time or the interest to delve deeper into the automation side of testing.
Usually the tester gaining the most from being able to automate they're tests are just so overloaded that they never seem to have the time to do check out the benefits of automating the boring basic regression tests that most application seem to need, i.e. is the logo still there, the submit button, the company information and so on and so forth.

I have seen several Let's get all automated drives in companies fail horrible. Usually these drives tend to share the same problems. Bing Bang approach and using too techy approach for non tech aligned testers.
Let’s look at them one at a time:

Big Bang approach to problem solving is usually bad and at the worst a recipe for disaster, if the problem is huge then solving it one piece at a time is the way to go. Where do you think that the proverb "divide and conquer" comes from... Divide up your problems and conquer each "mini" problem at the time and you will have much better success.

"Too Techy” approach to automation seems to be a normal problem. Usually the organization uses a certain programming language and tools. They then feel that, in order to maintain conformity, they must use the same languages and tools for test automation. This is a problem for many testers since they are often more analytical then "programatical" (did I just invent a word oO). Why not let the testers use an easy to understand and light scripting language instead (and for the love of God I hope you do not think of Perl as one of those). That way the big hump to overcome when starting automation is lessened. A good slide show about this (and very related to this topic) can be viewed at Mountains to Molehills: A Story of QA

Confronting the problem

So how do we get people that are busy or not really interested to develop a spark and interest for automating they're testing?
I find it best to confront this from the “basic” regression test side. These tests often get ignored or skipped or worse when under pressure. Everyone acknowledges that they really need to be run, but ...
So by approaching the problem from this side it is quite easy to get even the non tech-savy tester to get interested.
I am going to lay out my approach here, and then I’ll go deeper into each one further down in this (or next!) post.

Building Awareness

Point out the problem areas and offer to show them how you can help them solve them. Usually these are the basic regression tests. Then ask for a basic regression test case and bring that up (usually those are in excel). (Install and) Fire up Firefox and install the Selenium IDE. Start the IDE and and record at least two cases. Now run them in a suite.

This is usually enough to get a tester started. They see now that they can make a suite of easy tests and that it’s not hard! Now leave them for a while with the mission to make test cases in the IDE from those basic regression tests. It is very important to stress that if they run into problems in a case, it is better to skip that case and later bring that up with you (or go Google the problem). During this stage I usually send them some good pointers, like the Selenium IDE documentation page on SeleniumHQ.

to be continued...