What's the difference between SDE and SDET at microsoft?

What's the difference between SDE and SDET at microsoft?

I was exchanging email with a candidate last night who was confused about the differences between what dev and test do at microsoft, and as I tried to compose my thoughts about what it is that SDETs do, I thought that it would be good to share this on my blog.

You can envision the SDET job in two vectors, one in feature work, another in tools work. We have a product to test, and we need to eliminate defects, so we spend time in both proactive and reactive activities to help PMs specify the right thing, as well as validating what it is that our SDE counterparts built. Here’s the typical workflow for the feature work we do.

Feature Work

PM writes a spec for a feature. PM, SDET, and SDE sit down and discuss the feature, make changes and get general agreement on the spec.

SDET takes the spec, writes a test spec based on it, describing the testing in general terms. The test spec also defines an object model that you can think of as an API to the feature.

PM, SDE, and SDET sit down and discuss the feature spec and test spec, and agree that the OM defined by test is correct.

SDE begins to implement the feature

SDET implements the OM, and then starts writing tests against the OM.

As features come online

SDE and SDET together run tests agasinst the feature (manual, automated, and writing unit tests).

SDET does adhoc buddy testing against the feature to get more testing done before check-in.

Post code complete, SDE fixes bugs.

Post code complete, SDET analyzes automated test failures.

While there’s a lot to get excited about in both jobs (I can’t believe they are actually paying me to do what I do in my spare time for fun!) there’s drudgery in both jobs. Test case writing, automation analysis, and adhoc testing for the 1000th time can be mind numbing, but fixing bugs for a months at a time is equally as painful.

Tools Work

To extend our existing automation infrastructure, or to do testing in additional vectors, we build test tools. Lots of them. Test Labs can have 100s of machines, and if we’ve written the tests correctly, we can determine the current quality of the build far more efficiently than with manual testing. So while we do some manual testing, the focus is on building test automation that can be used milestone to milestone, release to release. Obviously, the quality of the tests and test infrastructure is super important. As the saying goes, who tests the tests, and who tests the tests that test the tests? Tests that don’t test properly can give false positives, and can actually be worse than no test at all because of the false sense of security they encourage. And infrastructure that is poorly designed will give you big problems as you approach v2, v3, etc., as well as sustained engineering efforts on your currently released products. So we have code reviews for every checkin, and we have design reviews for all tool work.

Some of these tools we created, some we took a snapshot of the code from other teams and make our own modifications, others are shared amongst many teams. Here is a list of some of the tools we build to test:

you like to get really deep in one technology space for long stretches

you don’t stop until you write the perfect algorithm, or the most elegant code

You are better suited to be an SDET if

You like system integration type work:

you take the technology that this team did, make use of it and tie it to this other piece of technology, etc.

You may have been a TA and graded other peoples code, or were the guy in group projects who enjoyed and was good at poking holes in other peoples designs

You have strong big picture thinking, and are focusing your energy on solving the whole problem.

You find yourself coming up with “good enough” solutions to problems. Your solutions may or may not be elegant or perfect, but you are happy with it and you’ve moved on to the next part of the problem.

So I describe the SDE problem space as more narrow and deep, and the SDET problem space as broader, not as deep. Some SDETs have more penchant for tool building, less for feature work, or the other way around.. In my group, I try to balance between both of them so that we get smart people thinking about the hard problems within feature work, giving them good cross functional exposure and scope of influense, and still mixing in a healthy amount of tools work. Other teams (many I've been on in the past) structure it differently, but my personal feeling is that this balance gives people the right amount of both for healthy career development.