I would like testers on an agile project to be able to code, preferably in some scripting language like Ruby or Python, secondarily in the languages their programmers are using to write products. In a note on the software testing list, Cem Kaner challenged that assumption. Here's my interpretation of his point. It may not be a correct interpretation, but it's the one I want to address.

As Bret Pettichord has pointed out (PDF), testers tend to be generalists. They know testing, but they also need to know the product's business domain. They might have a wide though uneven understanding of technology issues (like differences between Windows NT and Windows 2000, or between IE and Firefox). They need to have the "soft skill" of interpreting the desires of multiple interest groups because part of what they're doing is looking for the Customer's mistakes. As I've been learning from Jeff Patton, they ought to have some background in user-centered design. They're likely to switch projects more often than programmers, so they also need to be quick studies (which Bret also notes). So why then do people like me make such a big deal out of programming?

1. I would think less of a programmer who was unwilling to learn aboutthe things testers know. So I don't believe I'm putting a burden ontesters that programmers are exempt from.

2. I would think less of a tester who was unwilling to learn those things.What's interesting to me is that everyoneI consider a reasonable tester would agree with me. Programming sticksout (to me) as somehow being treated specially: it's a burden manytesters think they should be exempt from.

3. That's weird. So much of what afflicts testers is because they'recompletely dependent on the programmers to make the producttestable. Being able to program reduces that dependence, but beingable to talk to programmers in their own terms probably helpseven more. I've noticed that often, and Bret makes a point of it too.

On balance, it seems to me that programming is underemphasized as a part of a balanced tester's skill set. So I am justified in emphasizing it.

I suspect programming is singled out because of historical accident, though my hunch may be skewed by the circles in which I've moved. This is what I saw:

• In the 80's, when I was coming up, testing was too often a dumping ground for failed programmers. If you weren't good enough to be a programmer, you were sent to what became, by definition, a job for people without (the right) skills. It's natural to rebel against the value system of those who consider you inferior.

• In the 90's, especially during the .bubble, more testers seemed to be hired from non-technical fields. A history major I worked with is emblematic to me. She'd been hired fresh out of college into a startup. Given that programmers were magical (having the mystical power to turn elevator speeches into gold), it was easy to think they had mental powers mere testers couldn't hope to grasp. (Whereas I think competent programming isn't all that much harder to learn than lots of other skills.)

History needn't be destiny.