Three Reasons To Consider Being a Test Developer

Three Reasons To Consider Being a Test Developer

When it comes to careers in the world of software most people think of programmers or what are more formally known as developers. Developers are the people who write the software which is consequently sold or utilized by the organization. I’ll call them dev-developers to distinguish them from test developers. Sometimes people will also think of testers. Testers are the people who don’t program but run the software written by developers to find bugs. What gets lost in the shuffle is a specialized class of developers who are also testers. We like to call them test-developers. These are the people that write software to test software. It is they who will be the subject of this essay.

The term “test developer” is sometimes used to refer to a tester who knows a scripting language like Javascript or Perl or maybe even knows VB. Usually this person has no formal training and takes on only simple tasks. That is not what I refer to in this essay. The test developers I am referring to are a specialization of developers. They write complex code in production languages utilizing computer science techniques. See my previous essay on why test developers are real developers.

So, why should you consider becoming a test developer? Why not just become a dev-dev instead of a test-dev? That is the subject of this essay. There are three primary reasons to become a test-dev rather than a dev-dev. These are that it makes you a better programmer, the code you write is more broad, and it is at a sweet spot in the development cycle.

Programmers who are or have been test developers are, on average, better programmers than those who have not. They have a feel for what is likely to go wrong with software and so code for failure instead of coding for success. All too often those who have not been testers write code until it works and then stop. They write so that it can work but not so it will always work. Test-developers have practice breaking programs and so know where they will encounter problems. They are thus more successful at anticipating what error conditions may happen and writing resilient code.

Secondly, test developers tend to write code which exercises the product at a higher level. Instead of focusing all of your effort on a way to make a widget spin, instead you get to see what happens if multiple widgets spin at the same time or how spinning widgets interact with the IFoo class. Test developers write code that exercises the product as a whole which is often more interesting and more rewarding than spending time optimizing one little corner case. You get a more wholistic view of the product which leads to better understanding of how the various pieces interact. Additionally, you often get to do more fun work like determining ways to break the system, put various pieces together, analyze its performance, etc.

Finally, test development is at a sweet spot in the product release cycle. Dev-developers work furiously in the early cycle getting their pieces code complete. They then work furiously late in the cycle fixing the final few bugs. The end result is often very long hours. Test developers, on the other hand, are generally under less pressure. In the early product cycle, you can only work as fast as code becomes available to you. In the late cycle, your tests are already in place. If they aren’t, it is too late to add them. I don’t mean to imply that test developers don’t work hard. They do. They just tend to feel less deadline pressure than dev-devs.

If you have experiences as a test developer that you feel may benefit someone trying to make a career decision involving test development, please share them in the comments section.

http://blogs.msdn.com/steverowe/archive/2005/01/19/356361.aspx

[@more@]