Compartir a través de

Difference between STE and SDET roles at Microsoft

  • Artículo

What’s the difference between a Software Test Engineer (STE) and a Software Design Engineer in Test (SDET)?

 

The Microsoft career site has two excellent definitions for the Software Test Engineer and Software Design Engineer in Test roles at Microsoft. In my experience, these clearly defined role definitions have very vague applications here at Microsoft. After all, aren’t we all just assuring that the software that we ship is the highest quality possible?

 

Historically, it seems to have made a lot of sense that these two positions had distinct roles. Years ago, Software Test Engineers were testers who had limited programming experience. I’ve heard particularly frightening stories from Microsoft old-timers where Software Test Engineers were used as monkey labor- “Run this test fifty times, and call me if this breakpoint gets hit”. STEs didn’t need a strong CS background to get their jobs done- they just needed a lot of patience, and basic understanding of *using* computers.

 

The Software Design Engineer in Test role was reserved for Testers who were capable of writing tools and/or automation. I’ve also heard stories from other old-timers about STE hires that write tools in their first half year on the job having their job title switched by management to SDE/T.

 

It’s easy to understand the difference between STE and SDET with a black and white example. If you’re testing an API, then yes, you’ll surely be an SDET (how can you do any testing without writing a line of code?) Conversely, if you exclusively black box test a user interface (without tools/automation), then you’d have the job title of STE. The gray area between these two extreme examples is huge, though. I don’t know any STEs who don’t end up writing at least *some* code. In my personal experience, I’ve spent the past three months on the job writing automated test cases. Like many of my fellow STEs, this doesn’t strike me as uncommon. I'm sure there are plenty of STEs that in practice write more code than SDETs! This difference is particularly pronounced across different product teams at Microsoft.

 

Management seems to be pushing for a unification of these two roles, probably for this reason. Both roles dedicate themselves to product quality, both are reliant on strong fundamental understanding and application of CS principles.  A quick look on the career website seems to back this up- there are currently 326 active postings for SDETs, compared with 44 for the job title of STE. This doesn’t mean software testing is going away- I only see it as a reflection of the increasingly technical nature of testing software at Microsoft. It looks like the job title that the company is shifting to is SDET, which is more a mouthful but also more impressive sounding.

 

In short, don't be surprised if the name of this blog becomes "Software Design Engineering in Test at Microsoft" to match the way that the management wind seems to be blowing. If it comes to that, hopefully Chris and I can come up with less unwieldy blog title! :-)

 

-Greg

Comments

  • Anonymous
    October 06, 2004
    I have noticed that over the past couple of years, it seems that a lot of the groups I've worked in at MS now pretty much require you to be able to work at an SDET level in order to be hired for an FTE testing position. For the most part, it seems that STE positions (if any even exist) are generally filled by CSGs. I have heard of groups at MS (Exchange team is one of the names I've heard, don't quote me on that) where one day all of the STEs had their titles changed to SDET, and were told that they had a year to be able to be able to transition to the SDET level if they were going to continue to work there.


    And even in contract STE positions, I've found that I've needed to be able to write tools and code. In my current position I'm not necessarily writing automation, but do need to troubleshoot it on a regular basis. The SMS team has their own very well developed test harness which is token-based, meaning that most SMS tasks you would need to do (programs, advertisements, clent agent settings, etc.) can be written in XML tokens fairly easily, even including a drag-and-drop editor to put test suites together.

  • Anonymous
    October 07, 2004
    This is a pretty interesting blog and I chanced upon it pretty recently. Being a STE(CSG) I really like all the posts in this blog which has been very informative. I've always wondered the "real" difference between a STE and SDET and totally agree with you and the other reader.

    Now that STE positions are becoming more and more scarce and the push is towards SDETs how are the FT interviews gonna be like - more coding questions for a tester? I'm just a little curious.
  • Anonymous
    October 07, 2004
    Brian- Good observations, and I agree with what you're seeing. Of the STE CSGs that I've worked with, I've seen one who was an adept coder (with much more Microsoft testing experience than myself), and two others that tested UI without using code. All of the full time STEs I've seen hired in the past two years have had CS backgrounds- I don't think that would hold true across the company, but "my experience" has been that full time STE hires have been coders.

    Many of the product groups at MS here don't have UIs at all, and need to be tested via scripting and coding. These are the teams that I would envision a shift from STE->SDET occuring sooner rather than later, if it hasn't happened already.

    SV: If I was a hiring manager for an FTE STE role, my core criteria would still be- "Is this person a great tester?" If they pass that, then I'd make sure they have good programming skills for a `typical' position. If the position is programming intensive, then the candidate would need great programming skills, but they need a good tester mindset first and foremost. If you interview for a position that doesn't stress programming in the description, then you probably won't see that focused on during interviews. Or, you might see some coding questions anyhow- you never really can tell what kinds of questions you'll get until you're standing at a whiteboard. :-)
  • Anonymous
    October 07, 2004
    Brian- Good observations, and I agree with what you're seeing. Of the STE CSGs that I've worked with, I've seen one who was an adept coder (with much more Microsoft testing experience than myself), and two others that tested UI without using code. All of the full time STEs I've seen hired in the past two years have had CS backgrounds- I don't think that would hold true across the company, but "my experience" has been that full time STE hires have been coders.

    Many of the product groups at MS here don't have UIs at all, and need to be tested via scripting and coding. These are the teams that I would envision a shift from STE->SDET occuring sooner rather than later, if it hasn't happened already.

    SV: If I was a hiring manager for an FTE STE role, my core criteria would still be- "Is this person a great tester?" If they pass that, then I'd make sure they have good programming skills for a `typical' position. If the position is programming intensive, then the candidate would need great programming skills, but they need a good tester mindset first and foremost. If you interview for a position that doesn't stress programming in the description, then you probably won't see that focused on during interviews. Or, you might see some coding questions anyhow- you never really can tell what kinds of questions you'll get until you're standing at a whiteboard. :-)
  • Anonymous
    October 18, 2004
    The comment has been removed