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.
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
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
programmers are exempt from.
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.
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
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.)
needn't be destiny.
## Posted at 19:50 in category /agile