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.
http://blogs.msdn.com/b/steverowe/archive/2005/01/19/356361.aspx
No hay comentarios.:
Publicar un comentario