Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Sat, 22 Jan 2005

Testers who can script

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 about the things testers know. So I don't believe I'm putting a burden on testers 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 everyone I consider a reasonable tester would agree with me. Programming sticks out (to me) as somehow being treated specially: it's a burden many testers think they should be exempt from.

3. That's weird. So much of what afflicts testers is because they're completely dependent on the programmers to make the product testable. Being able to program reduces that dependence, but being able to talk to programmers in their own terms probably helps even 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.

## Posted at 19:50 in category /agile [permalink] [top]