James Whittaker is one of the most distinguished testers at Microsoft. He’s written a couple of books and is a well known in the industry for his work in testing – particularly in the Security field (see this interview). James is now the Architect for Visual Studio Team System – Test Edition. And he’s started blogging in the past month – check out JW on Test!
One of his posts, measuring testers, caught my eye. One of the things that I like to think about when considering performance is how much better a tester has made the product. A tester can make the product better in a variety of ways. Finding bugs in code before we ship is an obvious way and one that is easily measurable. Another thing that is fairly measurable is the quantity and quality of the regression automation that a tester writes to help us avoid bugs in existing code. Those are good ways to make the product better, but even better is the impact a tester has in the functional spec and design phases of a feature. Helping to build the right feature in the right way the first time has a much bigger impact on the product, but is also much more difficult to measure.
James’ post throws another dimension to this evaluation. James’ advice on evaluating testers is to ‘measure how much better a tester has made the developers on the team‘. What I like about this is that it is more sustainable than any of the things that I mention in the previous paragraph. Making lasting improvements through improved development practices (individual and team wide) on the team is a great thing to consider. How a tester is impacting the product in the short term is also obviously important, and I don’t think a tester should come to work with an attitude of “I’m going to make my developer peer better today whether he wants to or not!” But improved developers and practices is a logical side effect to great testing.
An even better way to improve developers is for them to be a tester! Some of the best developers that I’ve worked with are also some of the best testers that I’ve worked with – whether or not they have formally been in a test role or not. I especially like a developer career path that includes a tour in the test group.
James has gotten off to a fast start on his blog – check it out!