Tuesday, January 4, 2011

The Coding Tester

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.


  1. Completely agree. Cross functional teams are awesome with QA-folk who know how to code.

  2. As an ex-dev I've found I've missed writing code and am now getting back into it. What have you done to learn code and how have you taught yourself ?

  3. Phil,

    That's a good question, and it probably deserves a longer answer. The shorter answer is trying, Google, and friendly (and patient!) devs. I don't have a CS degree, so I'm living proof that you can learn even if you have a non-engineering background. I imagine it's different for everyone, but I've had luck with people doing things like:
    - sending them to a class at the local college or online
    - start with tiny scripts for things you do already (e.g., if you know how to do two or three command line things, then string them together in a bash file - that's code!)
    - if you work with other coders, try starting by modifying their code to add something you need

    Me, I learned starting with batch files (cleanupTomcat.bat was an early one) and simple shell scripts. Then came QTP and enough Java to manipulate recordings, followed by JUnit tests. Over time, I expanded more and more - bash, C#, perl, python, ruby - whatever I needed to do. Eventually it comes more naturally.

    I'm a small steps kind of person.