The Programmer Tester

James Bach gave a talk at Microsoft yesterday. Among his many points, he reiterated a few points he’s been making for years that got me thinking…so I thought I’d continue the thinking in this blog post.

James is concerned that Microsoft is hiring too many programmers to be testers. His view is that the “programmer testers” at Microsoft spend their entire day writing tools and writing test automation. This isn’t an uncommon feeling, so I can’t fault James for feeling this way. I don’t feel the need to justify this (too much) in this post, but I have written about this topic in the past.

The short version is, that for the majority of what we do, knowledge of CS is critical. We expect our testers to debug, diagnose, and analyze problems they run into. We expect them to recognize patterns of bugs, and have insight into how the computer may be using the data they input.

My experience is that a small number of testers with non-computer backgrounds can figure out how to do this (there are definite exceptions – I’m a music major!) . There are a lot of folks who are good at finding surface level bugs, but they rarely recognize patterns in the bugs they’re finding. I’ve seen a lot more CS folks who are fantastic “testing with the brain” testers – un-phased by unintentional blindness – who can leverage both the skills of their brain and their “skills”.

On the other hand, James is right to some extent. I bet we have  a number of “programmer testers” who are doing exactly what James thinks they are doing. They’re spending 50 hours a week creating tools and writing automation. Usually their automation isn’t very good, so they spend a lot of time “fixing” their code and adding “clever” workarounds. These folks are the exception and not the rule. I don’t like them either, but this isn’t how the majority of the testers at Microsoft are spending their day. (I’ve sort of talked about this before too).

In the end, like many other efforts, balance is the key. The best testers I’ve ever met have this balance. They know when to leverage their knowledge of computer science, and they know when to let their brain do the heavy lifting. They know what their limitations are and (if necessary) how to compensate for them. I think if James were to talk to more testers at Microsoft he’d understand that “testers who code” aren’t the problem – rather it’s the balance that’s the problem (keeping in mind that a great number of teams and individuals have this balance already).

Btw – James, if you read this, this is the 4th or 5th time I’ve heard you say that Jon couldn’t get a job at MS now because he doesn’t code. I’m pretty sure we paid him for his work on the Acceptance Testing guide :}

Comments

• Anonymous
  February 08, 2009
  The comment has been removed
• Anonymous
  February 08, 2009
  The comment has been removed