The STE vs. SDET Debate

What is the difference between a software test engineer (STE) and a software design engineers in test (SDET)? This is a question that is often asked because there is a lot of ambiguity regarding the roles of the STE and the SDET. Is the difference in the primary role in the organization, the skill set of a particular tester, or is it seniority in the team or company? As confusing as this subject is for many people outside the company, believe it or not, it was just as puzzling for many of us within Microsoft.

About 13 years ago when I first joined Microsoft the role of a SDET wasn’t so convoluted. In those days, it was very clear that a SDET was a tester whose primary role in the organization was to design, develop and maintain test tools and other testing infrastructure. But, it was also expected that many full-time testers in the STE role were capable of writing test automation, designing white box tests, and performing basic debugging skills.

But, over the years things changed. Some testers hired into some groups in the company lacked sufficient skills or aptitude to write automated tests or perform in-depth technical analysis of a software program. Sure, they were good at finding bugs. But, the less technically skills testers had difficulty performing additional testing tasks such as API testing or analyzing code coverage results to design additional tests from a white box test design approach to reduce under-tested areas of the product.

To differentiate the less technical testers from the testers capable of performing technical types of testing some groups decided to use the SDET title for almost any tester on the team who could write code in a modern programming language (particularly C/C++). This diluted the job requirements for both the STE role and the SDET roles. Also, the increased number of testers with the SDET title led to problems managing career growth.

Diluting job requirements leads to organizational nightmares. In some groups all testers with the STE title were still expected to understand a programming language or possess very specialized expert domain knowledge in a technical area. But, in other groups the STE testers were only relied upon to simply perform exploratory or ad hoc testing. Likewise, some groups continued to reserve the SDET title for those whose primary role in the organization was to build and maintain the testing infrastructure while other groups used the SDET title for practically any tester who knew a programming language.

This made it virtually impossible to establish standardized expectations for testers in comparable skill levels across the company. It also made internal transfers between some groups within the company very difficult for some testers, and it led some testers with coding skills to migrate to the groups simply to get the SDET title. Let’s face it; people want job titles that actually reflect their peer group. And, SDET sounds way sexier than STE. Of course the disparity in skills in the same group meant the more technically adept testers were getting higher review scores and being promoted at a much faster rate as compared to their less technical counter-parts.

The problem with career management primarily occurred because the SDET job role was never officially adopted by Microsoft HR, so our managers lacked guidelines for expectations based on an individual’s level. Some managers used the developer level guidelines, and some managers used a mix of the test guidelines and the developer guidelines. Similar to STE testers, SDET testers were not evaluated equitably across the various groups during annual reviews. Also, the proverbial ‘glass ceiling’ for promotions in testing forced a large majority of SDET testers at higher skill levels to transfer into developer positions where expectations and career progression requirements were better defined.

Recently, Microsoft implemented new career profiles designed to eliminate ambiguity in job titles, and establish clear guidelines for career progression. The new career profiles are well-intentioned, but haven’t solved all the problems. But, that is a discussion for a different day.

For more perspectives on the whole STE vs. SDET debate see Adam Ulrich’s posting and also Steve Rowe’s posting on the subject.