One of the things that most stands out to me when talking to testers is how variable their paths into test really are. There are testers who started in support and moved over. There are testers who were developers and decided test looked more fun. There are testers who got out of a computer science program in college, happened to land at testing job (usually with some sense of, "they want me, they really want me!" and never left). Some project managers and business analysts shift into testing. Every once in a while you'll get an end user who decides the software part is really fun and becomes a very knowledgable domain tester (ask me about the ex-nurse tester sometime - she was wickedly effective and incredibly good at convincing people to get the bugs she found fixed).
Of course, once you're a tester, how you got there is less relevant than your ability to do the job.* As systems change, the scope of skills we need to do our jobs changes, too. Most of us no longer have to worry about vacuum tubes or hardware wiring. More of us have to worry about APIs and load.
And here's my point: If you want to be a tester, know how to write reasonable code.
The systems I see today are getting both larger and smaller simultaneously. A lot of the software I see is moving toward the module UNIX (and variants) have been using for 30 years: many little components all working together. Every system is smaller, and does rather less - Twitter, for example, really only takes 140 characters in one input. Every system is also bigger, and combines with many more components - count, for example, the number of different programs that use Twitter's APIs.
When humans interact with a program, it's often through a GUI or a command line. That's great. But more and more, programs interact with other programs, and in order to test that, we're going to have to write some code.
We have to write code to:
- test APIs (our "user" is another program; i.e., some code)
- simulate things too big to do by hand (load testing, anyone?)
- break down components and test each of them (mocking, etc.)
Now I'm not saying coding is the only thing we do, or that it's a solution to all problems. I'm saying it's a tool in our toolbox just like the ability to write a coherent email or to explain a difference in behavior. We're not going to get very far without it.
So do yourself a favor. Don't go out to become a developer, but do learn to write some code. It's another tool that your toolbox needs.
* There are many ideas about what a tester's job is and isn't. That's not the point of this post so I'm just not going to quibble about it.