Why I believe it's good for testers to learn to code

Rob Lambert recently published a blog post with the title “Why Testers Really Should Learn to Code”. http://thesocialtester.co.uk/why-testers-really-should-learn-to-code Rob’s principal argument is that “The market demands it and the supply is arriving.”

What follows is an expanded version of the comments I made on that post.

First, Rob is presumably speaking about the market he knows best, i.e., in the UK. I’m not currently seeing such a heavy emphasis on coding in the Canadian market, though I think it’s probably there in Agile circles.

But regardless of the market demands, I think there’s a larger concern: about testers growing their skills and expanding their toolkits.

Whether or not testers “should” learn to code seems to be a contentious issue in at least some parts of the testing community at the moment. I admit that I’ve been observing the controversy with amazement. I’m having trouble understanding why any tester would not want to learn to code. 

I’m now a test manager, consultant and strategist, and I haven’t done serious hands-on testing in many years. But when I was a tester I knew how to code, and I worked at learning the languages I needed to know to understand and at least read the code for the applications I was working with. Working as a technical writer before I even became a tester, I learned to code and it seemed to me then to be an essential skill.

As coding advocates keep saying, you don’t have to be able to turn out production-level code. But it’s enormously helpful for a tester to understand how a system is constructed from the inside out. When you’ve tried to write working code, you learn to know the kinds of mistakes it’s easy to make with a given language and that helps you find bugs in other people’s code. And when you can read code, you can often spot the place where the error occurred and see what else might be wrong around it.

When you can code, you can write routines to build data in bulk, and also to inject data. You can write routines that help you test (or check) faster, or make it possible for you to test a larger number of input variations than you could practically manage otherwise. You can write and run your own batch jobs. You can query a database directly, to find out what’s really getting written to it. (SQL is code, too.) You can make clever use of spreadsheets to boost your test capabilities.

There are so many things a tester can do with code. And coding is FUN, folks! In fact, executing working code that you’ve written yourself is a blast! It’s almost as much fun as testing. (Okay, that’s highly subjective. But if you love software, why wouldn’t you love building some?)

There's a social aspect too. Being able to write code helps you understand your programmer teammates and it teaches you empathy and respect for their skills. (You want programmers to empathise with you and respect your skills too, don’t you?)

 

This is not to say that you can’t be a good tester without knowing how to code. Of course you can. I know lots of excellent testers who can’t code and don’t want to learn. I also know lots of terrific testers who don’t have (or don’t believe they have) exploratory testing skills, or visual thinking skills, and don’t want to learn those either.

In my experience, these and all your other skills give you tools you can use when the context calls for them. Not every tool is appropriate or useful in every context. But the more tools and skills you have at your disposal, the more flexible you can be and the more easily you can rise to the demands of different contexts. If you don’t have a particular skill, you may not even recognize how having it could help you test better in your context.

I don’t believe that the issue comes down to should or should not. Rather, I believe it’s about expanding your skills and your toolkit. Why wouldn’t you want to do that?