Do we as software testers need to have programming skills? This question is not new. It has been discussed back and forth for some years now. I don’t know if we as a community are heading toward any sort of consensus on this, but I’m going to throw my opinion out there all the same.

The short answer is ‘No, we don’t need to, but it sure can help’. There are plenty of reasons I can think of to have at least a rudimentary ability to cut code and no real arguments against (If you can think of any, I’d love to hear them).

The slightly longer answer is that there are many different kinds of testing and for some of them, strong coding skills are essential. For others, not so much. It depends on a lot of things. Do you have a dedicated toolsmith to build testing tools for you? Do you have others in your team who have strong coding skills and can put them to use for your benefit? If so, then you might get away with not being able to cut code. There are still advantages to being able to write your own code and understand other people’s.

Knowing how to write code can help you to build your own suite of helper tools that are perfectly tailored to the work you need to do (or easily adaptable to how you need to work), or even throw-away scripts to quickly take care of something repetitive. Having knowledge of basic regular expressions is a life saver if you need to do any sort of text manipulation or pattern searching at all (Knowing Awk and Sed can help too). If your toolsmith gets hit by a bus or your helpful code guy is too busy to help you out, you can carry on.

Knowing how to read code lets you look under the hood at what the program is doing. If you can check out the source code and read through it, you can spot things that may well change the way you approach your testing. How does the code handle error reporting? Are there any unhandled edge-cases you can see (often the answer is yes). That random number generator they’re using – is it custom built or native to the language? Are those tightly-coupled components going to cause maintenance or testability issues? These are questions you can ask and answer if you know how to read through other people’s code.

It can help you gain credibility if you have a hostile or indifferent developer group. If you can speak their language and report bugs to them in their terms, it can help cut down the ‘you’re just a tester‘ schtick. If you’re pairing with a programmer, you can code while they drive and you can suggest unit tests that can help out along the way.

You can look through the unit tests that already exist and understand exactly what they’re doing and what they’re checking. It might save you a lot of time checking something that’s already covered and vice versa, you can see the difference in what your programmers mean when they say ‘yeah we’re already checking that’ as opposed to what you mean by checked.

There are places where these skills will be in demand and some where they won’t. I know of some companies that do not hire testers without coding skills and there are plenty that make the STE and SDET distinction. The hiring thing I can understand if the team is small, but the STE/SDET thing I think is a bridge too far. You aren’t a failure as a tester if you can’t cut code. Some of the Rat Pack are coders, some are not. I happen to think they’re all brilliant testers. Being able to code is one small facet of the precious stone that is your testing repertoire. Not having it doesn’t necessarily devalue you, but being able to code can make the other facets of your testing stone shine more brightly.

If you’re a tester who has no experience coding, but is open to learning, my recommendation would be to pick up a copy of ‘Everyday Scripting with Ruby (for Teams, Testers and You)’ by Brian Marick. It starts out very simply (not quite ‘here is the on switch’, but close) and has a flow that makes it very approachable.

EDIT: Here are a few other  posts on the subject.

Elisabeth Hendrickson
Adam Knight
Lanette Creamer
Sauce Labs