tester skills

I wouldn't say better, so here it goes:


>A tester with no programming experience at all will not be able to keep up.

Keep up with what?

James Bach, Becky Fiedler and I are having an amusing time this week wrestling with bibliographic software. EndNote (Thomson) is the leading package, but it has bugs. Thomson bought out EndNote's leading two competitors a few years ago. Not surprisingly, progress in advancing the quality of the product has not been so quick.

From a bibliography management viewpoint, I think the EndNote people understand their market's needs well, but they have a multi-year history of corrupting files (including too many of my files). I suspect that their product might benefit -- A LOT -- from adding a few testers with stronger programming and debugging skills. As stands, Becky, James and I are each ready (enthusiastically ready) for a change.

So I was initially glad to see Microsoft bringing some competition to this market by adding bibliographic support to MS Word. I suspect that their software engineers in test did a fine job checking for file-corrupting bugs. On the other hand, I think this product would have benefitted enormously from serious evaluation by people who really understand how bibliography managers are used by graduate students, researchers and technical writers. In its current form, I think the product is useless for us as writers and I would not recommend it to my undergraduates when they are writing their first essays.

A tester with no programming experience will not be able to keep up with programming-related issues, but a tester with no understanding of the non-programming domains will not be able to keep up with those many aspects of the product's quality (quality = value to some person) that have nothing to do with the technical quality of the code but everything to do with whether it is worth using.

Rather than insisting that all testers be programmers or all testers be domain experts (as if any product involves just one domain), I far prefer a staffing model in which people have a variety of capabilities. Some people know code. Some people know peripherals. Some people know accounting (if that's relevant), etc. They cross-train, they pair-test, and they keep up as a team. Better a group of strong individuals than a group of mediocre generalists. And better a group of mediocre generalists than a group of programmers who know a lot of test automation and don't understand what the people who will (not) use the product will (not) use it for.

-- Cem Kaner