SDETs at Microsoft

Some time ago, MS began hiring primarily people with a programming background (industry or educational background) for test positions. As far as I know, there was no press announcement, but the idea seems to have worked its way into the overall global test community. Of course, anyone not close to information draws their own conclusions on this direction and what these people do (Bj has a post on this (with even more links) here). The interesting point (for me at least) is that MS has always hired "coders" for test positions – just not necessarily in the ratio we do today. The most common conclusion drawn is that we hire these coders for test positions because we want to automate everything and eliminate manual testing. While we do want testers who can write effective automation, that's only a small part of the equation. Testers who understand programming concepts and computer architecture typically have the analysis skills that testing requires. They can also (typically) find bugs earlier, and understand the root cause so that they can quickly find other similar bugs and implement early detection or prevention routines. I used the word "typically" in the above two sentences because not every good coder makes a good tester (not every "coder" makes a good developer either).

I often hear the argument that good testers are creative and are experts in their area. First of all, creativity (including creative problem solving) is a key attribute of just about any profession. Good programmers are creative too – for that matter, so are authors, secretaries, and zookeepers. The creativity argument is lost on me. As for the second point, the "expert" role and the "programming" role certainly are not mutually exclusive. In fact, I have known good testers who didn't know anything about programming. I have also known good programmers who couldn't test to save their lives. However, the truly fantastic testers I've met in my life fit the middle of that Venn diagram. Any good tester can find bugs. Today's software is in a state where finding bugs is pretty much like shooting fish in a barrel. We need testers that can find the bugs that exist today, but also implement quality improvements that will prevent those bugs from happening in the future – then devise techniques for finding (and preventing) the remaining bugs, and deploy these techniques efficiently across complex systems. Testers who understand programming are, in my opinion, are far better suited to these tasks.

Should testers without a programming degree be fired? Are you kidding – of course not. Any thoughts along that line are completely unfounded and irresponsible. However, if you asked me if testers should have a knowledge of software architecture and programming concepts, I would undoubtedly say yes. To me, finding bugs is passé and frankly, easy. Tomorrow's testers need to have the knowledge and skills that will help them find and prevent those bugs efficiently and effectively.

I could go on, but I think I've made my point.

Comments

• Anonymous
  February 21, 2007
  The comment has been removed
• Anonymous
  January 28, 2009
  James Bach gave a talk at Microsoft yesterday. Among his many points, he reiterated a few points he’s