Tools Do Not Convey Knowledge

Let's say you've decided that you want to change the oil in your car. You don't want to take it to a shop, you want to do it yourself. So you go into Sears, find the Craftsman section, and purchase a mechanic's wrench set, an oil pan, and some jacks. You're all set, right?

One minor issue - you don't know *how* to change the oil; you've never done it before. But these tools were expensive, and they're supposed to make the job easy, so there shouldn't be a problem, right? So now, you get back to your house, crawl under the car and start messing around. After a few hours of frustrated cursing, you emerge from under the car covered in oil, your knuckles are torn up and you've damaged your car so badly that it'll need to be towed. You are all set to call Sears and light into them about what crappy tools they make because you couldn't even do a simple task like change your oil.

While extreme, and perhaps a little ridiculous, this scenario is exactly what happens when a company blindly introduces an automation tool without seeing if its people have the skills needed to use it properly. The statement "Automating tests is easy, you just click a record button" could be equated to "Changing the oil is easy, you just drain the oil and put in fresh stuff."

Make sure that you have a good understanding of what's going to be involved in your automation efforts before you put a tool into play. Do a small pilot project or proof of concept against a piece of your application and see if there are any surprises. That whizzy custom control your developer whipped up may only be accessible to someone who knows C#. That database test you want to perform may only be possible by someone who can write SQL stored procedures. Make sure that your people have those skills before you ask them to dive right in to automation.

Remember, tools enable people to work more effectively, but people need to understand how to use those tools before that can happen.