Starting to see a lot of good discussion about what it means to be a test developer and the practices, ideas and challenges that go into being a successful test developer. In this post I want to talk about some insights about what I find challenging about this role and a question as old as the chicken and the egg conundrum:
Are test developers, just wannabe developers?
This is a thought that crosses the mind of most people who have worked as or with test developers (also known as Software Design Engineers in Test or SDETs) within Microsoft.
Being someone who originally came from that traditional school of thought that testers are just developers who couldn’t make it as devs (similar to dentists being labeled as doctors who couldn’t make it), it has taken me some time to wrap my head around the SDET job description and grow an appreciation for it. You also have to pacify your ego and let go of the prejudices. Well I did and now I am hooked onto it and think it offers a lot of great incentives not available to a traditional SDE, such as flexibility in coding, high-level view of the system and a more egalitarian workload across the product cycle. All these and more are tackled by Steve Rowe in his blog postings about why a test developer role is better than a traditional developer role and why test developers are just as “real”. I liked the posts and ran into them through the Careers@Microsoft posting.
Other than these, one additional challenge that I have just begun to realize, is that as a tester, you are always trying to cope with a lot of theoretically hard problems (testing space in most cases is unbounded) and I find dealing with this computational complexity especially rewarding. It’s like trying to tame a wild horse…:)
You can also read up over here, about differences between the STE / SDET positions and how vague and thin the line really is at times.