I got an email from a fellow tester recently asking what he could do to move from manual testing to automation. Here’s my (slightly edited) reply:

Shifting from manual testing to automation involves two main things I can think of from the start.

The first is obviously technical. You need to learn programming. How much depends on the tool you use. Some tools help hide the details of programming, but since you mention Selenium, I’ll assume that’s not what you’re talking about.

It doesn’t take much to learn the basics of programming. But it’s easy to miss some important principles and work harder than necessary creating less than optimal code if you don’t understand good programming principles. I won’t go into that in detail here other than to emphasize that the better programmer you are, the more reusable and maintainable your automation will be.

Apart from the technical aspect of programming, I think good testers already have many of the traits of good programmers — analytical mindset, precision in language, creative problem solving, and and attention to detail.

The second thing you need when moving from manual testing to automation is more subtle. And that’s shifting from an exploratory mindset to a defensive mindset. More plainly, you won’t be looking for problems with automation, you’ll be looking to prevent problems.

Your goal with automation should be to check that software is valid, not to find problems. As a manual tester, you’re rewarded for finding subtle problems — but as an automated tester, you’ll be limited to what you can anticipate with your automation, or you’ll tear yourself up trying to write predictive code.

The goal of automation isn’t to find new defects, it’s to verify expected behavior, and to stop regressions.

There are two points to keep in mind when you write automation.

1) Everything can’t be automated, nor should it.

Some things are too hard to automate reliably — or take too long to do so. Some things are easier and faster to do manually. And automation can’t notice anything wrong that it’s not specifically told to check for. Humans can.

2) Automation frees up manual testers to do exploratory testing and provide rapid feedback on things that are not easily automated.

Automation doesn’t replace manual testing, it enables it.

You should consider automating things that are repetitive, error prone, or to slow to do by hand. But you should also realize that not having a human check an area of functionality means that the person would not notice if other things go wrong (even simple things) in related areas.

Personally, I still like testing. And I like that my automation helps me to do better testing. I’ve found that when automation is not an expression of my testing (e.g. when I’m only writing automation, and not also doing exploratory testing) that not only does quality suffer on the product, but that my automation is less effective than it should be.