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.
http://blogs.msdn.com/b/imtesty/archive/2006/05/19/601600.aspx
No hay comentarios.:
Publicar un comentario