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?