Reasons to be a Test Developer

Steve Rowe has an excellent blog post on Three Reasons To Consider Being a Test Developer (aka SDET). Nihit Kaul also follows up with some interesting comments here.

One piece I'd like to add about the advantage of being a Tester (whatever the job title : ) is that you'll learn your underlying product literally *better than anyone*. It's true that PMs have put their sweat and blood into creating detailed Specs, and Devs have literally built the application from the ground up and have an extensive knowledge of underlying algorithms- it's their own code, after all! Ultimately, I would have to argue that the Tester of a feature is going to have the most knowledge of the in's, out's, upsides, and downsides of the features.

Why?

It's our job! We've spent such a long time hacking away and learning our feature, that we've inadvertantly picked up full expertise from a true power user's perspective. When we think of a user scenario that's outlandish but possible and should be supported, a Tester is the only member of a product team with the freedom to go ahead and try it. PMs have their hands tied, and Devs are already busy off writing more code.  An SDET is free to write automation to learn exactly where the product works, and exactly where it doesn't. And, they're probably happily doing some exploratory testing when they become inspired to search for a potential bug that may have been hiding.

From my own experience, when a question comes up in a meeting like "How do we handle environment condition X when executing feature Y?" - all eyes at the table will drift to the Tester, and they'll usually know the answer. :-)

Greg