digital pity: Monday, October 24, 2005 at 10:04 AM by Randy
Random work related entry.
What is a Software Design Engineer in Test [SDET]? In it's most abstract form, an SDET is a developer that writes software with the purpose of testing other software. In 'softie terms, if SDE writes software with the focus of producing a product, an SDET writes software to test the SDE's product. It's what I've been doing for the last 16 months, and for the most part it's been a satisfying experience, although there have been a hiccup or two recently... but the question I that of role: "what does an SDET do" for a product.
As part of the MSDN "in product" team, I am a person with a foot in two different groups: I work with MSDN content with a the focus of supporting Visual Studio, SQL Server, and any other application that uses the Document Explorer application. You can imagine that with Visual Studio and SQL Server 2005 shipping in a couple of weeks, work will be slowing down to a nice normal level. Great imagination and one I'm jealous of. Once the English version ships, localization efforts will continue, as will the work for VS Team Foundation: we're hardly "done" with this process, even after the shiny boxes appear on store shelves... not to mention that our Quarterly Library and monthly TechNet shipments: those continue year round.
And as the cycle continues to ebb and flow, that brings me to my musing of what is a Tester in 2005.
My first "real" job in the software business was in a test organization, working for the now-legendary (and non-existant) Enterprise division of Symantec Corporation. It corrupted me, this working for a solid company with fairly deep pockets of money to make payroll: I never thought about a career before I started working there... was a good incubation environment for a young QA Analyst. After my local office moved from CT to CA, I stayed in CT and started on a career as a developer, which kept me entertained and well stressed for a number of years.
Stressed? Yes, stressed. I never seemed to have enough testers for any of the projects I worked on! I saw this as a problem, but I did what I could. Not to mention the constant worry about where the next paycheck was coming from... anyway, I always liked coming into my Dev role from a Test background: it made me more conscious - or at least understanding - of bugs than I think I would have been if I had started out as just a coder. I'll never forget one Dev that worked for me at one company that not only told me that he didn't have any memory leaks in his code, but that he had never seen the Output window in VS. I guess he'd never bothered to look at it before... incidentally, he was working in C++, using new all over the place and never calling delete. It's for hacks like him that managed code was created, the doof.
Anyway, back to the question at hand. In the mid-90's, QA was considered to be a gatekeeper for products. Nothing should ever be released until QA blessed it. QA was on the hook for everything the product did; any problems would be traced back to QA. Except when QA was overruled, which happened a few times in the life cycle of the Enterprise products group. As I recall, we dubbed our 1.1 version as "Now with error handling!" We didn't win any brownie points with the VP's, I can tell you that, but we stood by it as the truth.
Now it's 2005: what's Test's role these days? Less of a gatekeeper's job, I can tell you that. It's more of an assessment of quality. Blame for bugs that slip through will impact all three parts of the product team (Dev/Test/Program Manager) so Test doesn't stand alone anymore. Also, because modern products can be so large, there's no one feature teams that can assess the over all product quality - it's subdivided for the teams - so one Test team shouldn't be able to determine what is "good enough". I report on what my features are doing, and what they should be doing; what that translates to in release schedules is not my call.
We are witnesses of quality, more or less; we live to tell other teams what is and is not working in the product. Or as I like to think of it "Whipping Boy, Scapegoat for Excellence". After all, even within modern companies, there are still Developers that look down on Testers as inferior workers or second class citizens. It doesn't happen nearly as often as it used to, but I've still felt it in spite of having a full decade of developer experience... Whipping Boy is still very much in a Tester's title, not for the faint of heart or thin skinned.
The follow up question to "What is an SDET?" is whether or not it's something I want to stick with, long term.
With the right project, it's a great gig. You are empowered to assess quality, improve your tech skills, assist all aspects of the team, and be a part of a great product. With the wrong project, it's a nightmare on many levels: all of your assessments are ignored, you can hardly ever get an accurate test due to code churn, and you realize, long before the project ends, that it will be your neck on the chopping block even though you've done everything you could to ship a quality product. A tale of two worlds - or an episode of Mirror Mirror, you decide.
In my current role I'm tied to two projects: one online, one offline. Sort of a Ying-Yang deal. The offline project is kick ass and has been for over a year. Solid processes in place, interactive developers, well documented product. The online project feels like a tightly tied plastic bag that's been wrapped around my face, before having my head shoved into a hole in the dirt like an ostrich. While the individual team members are solid, the overall process is a wreck and that impacts effectiveness. What's a Tester to do? A Tester instinctively analyzes the situation for quality... and I'm not too happy with what I see. The question remains: has this been enough to soured me on my current SDET role? Hard to say. Now is not the time to consider it, as I'm still knee deep in bits, but it's a question that will be answered over time, I'm sure.
Being an SDET in a wrong group, sucks big time.
Plain vanilla GUI testing SDETs learn nothing from MSFT.
This is coming from a real life SDET working on a pathetic project. So if u got a job as an SDET...great...but make sure that you analyze the group you are joining atleast 15 times. I am warning this coz...you will not feel you have lost your career being an SDET...even though u r in MSFT.
But that's the trick with any role? I mean you can be an SDE and LOVE coding and developing, but if you're the poor bastard that has to work on the "Pearl" in Office 12... how rewarding is that job? It would be the same for an SDET that is forced to do nothing but ad hoc testing on a menu or toolbar 8 hours a day for 6 months. If the project sucks ALL of the roles are going to suck. I've had Lead from other disciplines suck the life outta otherwise good projects - always a constant balancing act.
Hi, i got selected for MS-IT, Hyderabad.,
as an SDET..
I am in my final year of engineering, in Bangalore..
have I made a right decision??
anything I need to do before joining?? ( my joining will be by July, 2008)..
Any technical or non technical preparation required??
I still didn't understand about groups(in SDET) which you discussed here..
Well, I'm not sure if I fully understand the question... I mean if you took a job and don't know what the position is, then I'd say you're in for a world of trouble!
As for needing to know anything before joining, I'd always recommend reading Code Complete, Second Edition and Writing Secure Code, Second Edition - those should be required reading for *any* Windows programmer. Beyond that, I'm a big fan of James Whitaker's books/talks - even before I was an SDET - because they help you look at things in a completely different way (which is good for security testing).
Posted on: January 02, 2008 at 09:54 AM by Brian Lang
I'm looking for a Software Design Engineer that has experience with Testing, Coding, C#, C++, VB, White box Testing and testtool Automation. Please feel free to email me or call me if you or anyone you know is available or interested.
Sir,
I am a final year engineering student and have been selected in MAQ SOFTWARE, INDIA as SDET ,a Redmond USA based company. please help me out what is career path and growth in joining such a small and new company as SDET.and can we switch from SDET profile to SDE.
thanks in advance :)
I'm not sure what you're asking me, really, but I will offer you a piece of unsolicited advice: don't take a job as an SDET if you don't want to be an SDET. I mean, if you wanted to work on cars as a mechanic, would you go work at a bike store and *then* ask to change, before you've even started?
If you want to be an SDE, then apply and interview for an SDE position. Just because you're an SDE does NOT mean you can be a successful SDET. The skills are often as technical for each but the roles are totally different, which is why there are two roles. There are many coders that are SDETs that wouldn't make good SDE's - there are many coders that are SDE's that wouldn't make good SDET's.
At least that's my view and my advice to people looking for work. Especially for SDET's on my team - there have been SDE's that aren't technically deep enough to work as an SDET for me... says a lot about what I think an SDET should be.
I have an offer for SDET position from MS.
I am a developer and don't want to make a career in testing.
Do you think that I should take up the position ??
I have about 2.5 yrs of dev exp and its still early days in a long career and I certainly don't see MS as last destination for me. So how would my next employer look at me if I have been a SDET as MS. I mean would I be considered a developer or a tester??
Also I have been told by MS Hr that they look for same level of coding skills both for SDET and SDE. If this is true then how do they decide whom to offer which position ??
While people have been asking how SDETs can move to SDEs. I wonder if any SDE moves to SDET role ??
Is flow of people in both directions balanced ??
Well, my general advice has two parts: 1) every dev should be a tester at some point in their career, the earlier the better, because it makes them far better coders. It also makes working with unit tests better (which I'm also a firm believer in). 2) don't take a job that you don't want or you plan to use as a stepping stone to something else.
The first bit is pretty straight forward. The second bit is as well, but there's a different reason for that. If you want to be an SDE, be an SDE. If you plan to be and SDET as a stopgap solution, simply to get into Microsoft, then don't apply to my team - it's one thing to work on a team for 1-2 years and then move on (be it to other teams or other disciplines) but there's a danger it doing it on purpose. I find that most people that become SDET's just to get in the front door half-ass their first gig... that means no praise, no kudos, and with a first year record like that, what do you hope to do?
As for movement within disciplines, there's lots of movement. I know that a number of SDET's in my group used to be SDE's in previous positions; I've known a couple of people that have gone SDE after being an SDET. Right now, two of my direct managers have had a Test background - a number of PM's have also had SDE experience.
And yes, an SDET at Microsoft is seen as a coder that focuses on test. Some SDET's have more coding than others - that depends on the team - the same way there are a SDE positions that focus on internal tool creation rather than customer facing product... it's all coding but it's about where your focus lies. Having said that, after a tenure at Microsoft, people that know MS will know that an SDET gig there will have involved coding; for those that don't, it would be up to you and your resume/cv to showoff your coding experiences.
HTH!
Posted on: January 27, 2008 at 07:59 PM by Ben Weber
I run an IT staffing firm in Bellevue, WA here and we're currently inundated with SDET searches from various clients. It seems like everywhere I look local firms are trying to find the allusive "SDET" these days - good ones - much like Randy describes; those who love what they do and truly appreciate their part in the overall process. So for those wondering whether or not pursing an SDET career path is the right way to go, I'd say IMHO, absolutely yes.
There seems to be no shortage of positions available in and around Seattle at the moment and we all know what limited supply and increased demand can do to the market. My question for you Randy is this: did MSFT coin the acronym SDET, because I need almost two hands to count the different companies currently asking for them?
Hm. Interesting question... and one that I actually wanted to answer at this year's GDC but they didn't pick up the talk *grumble* but anyway.
I will say that the first time I had ever heard the term Software Development Engineer in Test was when I decided to apply for work at Microsoft. They were the first company that I knew of that actually had two levels of testing: SDET and Software Test Enginer. The former focused on writing code to test code; the latter focused on manual testing (and type of tests that only manual testing can do - like web design or dropping discs into drivers). Today, the majority of Test is of the SDET variety; now - more than ever before - do you have coders working to test software.
When I first started, I was working for a yellow-box software company out of Cupertino, CA, first as an SQA Analyst and then a Lead SQA Analyst. Back then the majority of the testing was manual but that Test team was also unique in that they had their hooks into everything: design, documentation, deployment, CS, marketing, training - the only thing we didn't get into is coding the product.
After that I spent over 9 years as a Dev because of the companies I found didn't give a rats ass about test - since I could code and design, I went down the Dev road. When I joined up with Microsoft, I did so as an SDET because I would still be coding but I would also be testing - sort of a merging of my career path at that point. In addition to that most teams at MS look at Test to fill the role that my original QA team: they do more than just look for "quality assurance" - the help to drive quality thru the process.
The talk at GDC would have been about how Test has changed over the years... how it's gone from being the last step in the process or acting like gatekeepers for software. This is a lesson that I believe a lot of game studios should learn, since they have a huge dependency on manual testing; maybe next year.
But the point is that Test should now be reporting quality throughout the process: Test is a voice in the chorus. It is there to find places where quality is suffering, point them out, offer an opinion of why (and sometimes how) you want them fixed, and then go onto the next problem. Do you fight for bugs in Triage? Of course! But you no longer have this mentality of "WE ARE TEST - YOU DON'T SHIP UNTIL WE SAY SO!" because Test has never had nor shouldn't have that kind of absolute power. Voice in a chorus. Sometimes a loud voice, but still one of many.
So yes, if other companies are looking for a successful implimentation of Test, they are right to look at Microsoft. If other companies *are* looking for SDET's I'd say that they either got the idea from Microsoft or someone that worked at Microsoft... other software houses may be doing the same thing, but I know the term SDE started here - makes sense that SDET did as well.
Thanks for the great Post. How about Program Manager positions? Does Microsoft recruit experienced developers without any PM experience as Program Managers?
I did receive couple of calls from different MS recruiters but all of them were either SDE or SDET positions. When I tell them I am more interested in a PM position, that has been the end of it so far :)
It depends on the PM position. There are certainly entry level PM positions that they will hire for - the developer experience is usually a bonus - but it really depends on the position. As an example, all of our PM's in my group can code; they've all been devs in past positions at one point or another - it works for our group. In other groups, teams need people that are more about project and people and resource management... I know that I once applied for what looked like an entry level PM and it turned out to be a PM position for a team in DevDiv that had 150 people - NOT the gig for someone looking to cut their teeth on a new role :)
Posted on: March 14, 2008 at 02:40 PM by Walter Jones
Rohit, you should not work for MAQ Software in any capacity. Unless you want to work ungodly hours for sub standard pay and poor benefits.
Posted on: April 14, 2008 at 05:48 AM by Guruprasad
Hi randy,
As i am working on DQA and Test Services for Microsoft Dynamics AX.
What is the scope of Test Services?
Does this belong to SDET Category?
Also i want to know the future of this Test Services?
To be honest, I have no idea - I have no knowledge of Dynamics and never heard of DQA. But take some comfort in the fact that I work in Xbox LIVE so the odds of an overlapping technology with Dynamics is nearly 0... sorta like asking the brakes guy in a factory about the lift in a dealership :)
This forum is very useful for all folks who have MS offer in their hand.
I would like to understand more on SDET in SQL Compact team. It would be great if you can compare the kind of Research required to do jobs in SDE & SDET.
I am keen to develop features that require research & development. I have come from a background where we have a concept of SME, and have done manual & automation testing at some level as well, however that doesn't excite me.
So should I select SDET as my career at MS?
For me SDET is completely a new concept and HRs, as we know, are very strong in convincing the SDET positions. Infact HR is very open to say at very first stage about move from SDET to SDE, this itself creates confusion in my mind for SDET position.
The views expressed on this web site are mine, and mine alone. They do not reflect the views of anyone else, including my employer, and they are not endorsed or approved by anyone other than myself: my opinions are of my own design.