What does an SDET do?
March 31, 2007 at 7:49 pm | In Microsoft, Software development | 27 CommentsI’ve been meaning to write this post for a while now but I’ve just been so busy at work at the moment, I just haven’t had the time.
In this post I want to cover what the role of an SDET at Microsoft is. As most of you already know, I am an SDET, or Software Development Engineer in Test, with the Windows Serviceability team at Microsoft.
Unfortunately, sometimes people call this person a ‘Tester’ which I find to be a bit incorrect, as the job does not involve only testing. In previous companies that I have been in, you typically have the software developer who creates the code for the software, and then you have a tester who tests the software through black-box testing. In case you don’t know what black box testing is, basically the tester does not get to look at the code and just tests the software interface that is presented to him/her. This is not what an SDET does at Microsoft…Typically, most teams have Software Test Engineers (STE) that do this kind of testing. It is their job to test the software, identify failures, analyze the log files, and report bugs to the SDET.
At this point in time, you are probably thinking so what is the the role of the SDET…Well, here is a list of what I think to be the important aspects of being an SDET:
- Developing new tests. This is pretty much one of the biggest things that an SDET has. They must work with the developers and PMs in order to identify what needs to be tests in new or existing features in the product. The SDET has full access to the code and the design of the component, so typically this is considered white box testing. Being able to look and understand the source code allows you to develop much better and more targeted tests as you can see what the typical boundaries are, how the code works, and what code paths need to be tested more than others.
- In-Depth knowledge of the code. Sometimes you need to know the code even better than the developers. Usually when a new developer comes onto a team, he doesn’t necessarily have to understand every aspect of the code…just usually his area, or the area that he’s writing – so when he gets a bug report he can easily fix it. The SDET does not have this luxury, he needs to not only understand every aspect of the product, but as well he needs to know how it interacts with all other components (and when you are dealing with a product as large as Windows, the challenge can be immense!!)
- Excellent debugging skills. Debugging code can be a huge field by itself. I’ve attended a couple of courses at Microsoft, and it can become really complicated and advanced. But to be a good SDET you need good debugging skills. You need to be able to take a failure in a test case and then troubleshoot it down to the problem function. This can sometimes get tricky when you are dealing with threads, timing issues that disappear under a debugger, or memory corruption.
- Writing Code. Some people think that an SDET doesn’t really need to learn or write code, but that is far from the truth. A good SDET will write lots of code. An excellent way of testing involves using automated test suites. It actually is a necessity when you are dealing with hundreds, and thousands of test cases. SDET’s are the ones that write these automation suites, and write the necessary code to test their components. In addition to this, SDET’s write tools and utilities that help them in their jobs (for example, a tool that will generate logs, or fuzzers to test their programs). Also, some SDET’s participate in miscellaneous projects that pop that seek volunteers (for example for diagnostic tools that help product support).
- Enjoy breaking things. Developers typically create and hate it when they find a bug in their code. SDET’s have the opposite mentality…They usually like to find new and interesting ways of breaking the software and are very happy when they find a new bug. Ever since I was a child (much to my parents anger) I loved taking things apart to try and figure out what makes them tick. You need this type of mentality in order to be a great SDET.
- Being a good consumer advocate. It is the SDET’s responsibility to make sure that we are shipping the highest quality code possible. It is his/her responsibility to advocate the right bugs to fix and to reject the ones that would introduce too much risk to the customers. It is a very big and very real responsibility that an SDET faces with every bug found.
There is a lot more useful and great information found in the following JobsBlog article which describes the role well. It also identifies what a recruiter looks for when looking for an SDET.
In addition, if you wish to learn more technical information about testing. I found the following books to be excellent and would strongly recommend reading them:
- The Art of Software Testing by Glenford J. Myers
- Testing Computer Software by Cem Kaner, Jack Falk, Hung Nguyen
- Writing Secure Code by Michael Howard and David Leblanc – If you are interested in testing for security bugs, then this is a must read. I have read this book, and have attended some talks by Michael Howard as well. Not only is he interesting, but he knows what hes talking about
Looking at Amazon, it seems a new version of the book is coming out on April 11th called Writing Secure Code for Windows Vista. I definitely need to check it out - Code Complete by Steve McConnell. Excellent book and has a good section about testing too.
If you have any questions about the role, or if you wish to discuss it here – please feel free to. I am looking for as much feedback as possible!
27 Comments »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.
You are right, SDETs gain breadth knowledge, while SDEs gain depth knowledge.
I know what you’re talking about well because my first position with MS was a performance engineer, a position very similar to SDET
Comment by Mohamed Meshref — April 3, 2007 #
hmmm. I didn’t know that. I just assumed SDETs were testers. But now that I know, I think it could be more fun than development
Comment by Mak — April 3, 2007 #
Meshref – yes you are right. But SDETs still do gain depth knowledge and they have to use it. You need in depth knowledge of your component + you need breadth knowledge to know the interactions with other components
Mak – Thanks for visiting. Yes – While in Egypt a testers role was just limited to black-box testing and was generally looked down upon by developers. After learning more about the role, and reading The Art of Software Development – I realized testing is a huge field…there is an art and there is a science to it – and just because you’re in test it does not mean you stop doing dev. work. I love programming…always have and always will…Plus to be honest, its a lot easier to write code for the first time, than to go in and understand code that was already written
Comment by aliabdin — April 3, 2007 #
Ali, what’s a good book for test cases. Meaning finding test cases for basic algorythm problems?
Comment by mr E. — April 3, 2007 #
mr E. – I am sorry but I do not know of a good book that will just list the test cases for basic algorithms….Usually though books regarding testing show you how would you come up with different test cases for things. For example some things you can do: Check for correct behavaior, Check for error conditions, Check boundary conditions (e.g. if a function takes a number between 0 and 100, then try -1, 0, 99, 100, 101). There are also different buckets you can test for (e.g. performance, reliability, accessibility, usability, stress, compatibility, etc.)
I hope this is a good guideline for you to come up with your own test cases (which is a good exercise).
Comment by aliabdin — April 3, 2007 #
I know what you’re talking about, what I mean that SDE is more about depth, SDEs also must gain breadth knowledge (because they are not creating isolated components) but they gain depth knowledge more than breadth, SDETs is the reverse of this, the amount of breadth knowledge they gain is more than the depth one.
Comment by Mohamed Meshref — April 4, 2007 #
Ali,
I’m interviewing for an SDET position soon. Do you have any study tips and or things I should focus on?
Comment by Abhijeet — May 3, 2007 #
Well I would definately recommend the books I have listed above. They are good resources and also read the post to evaluate for yourself whether you want to be an SDET…
Also I would recommend reading the post I wrote titled Preparing For the Microsoft Onsite Interview.
The most important thing to understand and focus on is algorithms I think and being able to use them in real-world scenarios. This is for the on-site….The phone interview is more broad and I have some tips for that in my post Microsoft Phone Interview Tips
Good luck and keep us updated!
Comment by aliabdin — May 3, 2007 #
Ali, is SDET treated is a lower employee at MSFT? Do they get paid less? Do they get the same benefits and access to same resources?
Comment by mustafa — July 12, 2007 #
Hey mustafa,
An SDET is now treated as a “lower” employee at all at Microsoft. They do not get paid less and have the exact same access to the resources as the SDE’s (e.g. same trainings, same access to source code etc.) There are also SDE’s who switch to SDET’s and vice versa…And yes they also have the same exact benefits.
Comment by aliabdin — July 12, 2007 #
Thanks SO MUCH for this info. I’m a recruiter at MS, and this really helps define the role of the SDET from someone actually doing it
Comment by landinn — September 6, 2007 #
Ali, once we have worked in an SDET role, would it be difficult to move out of it. Or how difficult is it to move out of it? For example, if I need to move out of MS, say, because of some personal reasons, ….. would it be difficult for me to get into Dev position in other good companies, (not all companies have a role like SDET, and I would not be interested in regular (blackbox) testing that other companies would be doing). Will we get type casted as QA or testers? Will working as SDET in MS mean end of Dev career else where too?
Also, in what situations can we switch to an SDE from an SDET? How often have you seen this happening or the reverse happening?
Comment by ccracy — September 15, 2007 #
These are some very good questions and I am not sure I can give you 100% answers to all of them. The best I can do is give you opinions.
- I am not sure how difficult it is to move from SDET to Dev…At MS I believe the flexibility is there, but since I haven’t tried switching I can’t say…
- It seems though your question revolves around leaving MS as an SDET and going to a company. The problem here is it will vary depending on the company. A good reputable company will understand that SDETs write a lot of code too and can work as Devs too. I would try to emphasize on your CV the Development work you have done. Once you have an actual interview with the company, this is your opportunity to shine and show your technical Development skills too. In general though if you are going to a smaller company that doesn’t really get the SDET role, most would love to have any kind of engineer that’s been at MS due to the experience.
- As for your last question…I haven’t seen/heard of a lot of SDE’s going to SDET although this is definately an option and choice for these people and I am sure there are people who have gone that way. I know that a number of people have switched from SDET to SDE for the reasons you’ve mentioned above, including a few other reasons. But I think what it boils down to is – what are YOU more intersted in. Each one has its own set of challenges and interesting problems, so you have to try to evaluate which one you like more and do it. In addition, the more advanced you get in one of these roles, I think the hardware it will be to switch (due to specialization) but at the same time you become a subject matter expert so you will be more valuable
Hope this helps.
Comment by aliabdin — September 17, 2007 #
hi do you everp lan to switch from sdet and sde? and how easily would you be able to?
also are sdet’s looked down upon at microsoft by anyone?
Comment by anonymous — November 30, 2007 #
I do not know if I plan to switch from SDET to SDE. At the moment I do not have any plans for this as I am very happy in my role, and there is a lot of development work that goes into test too. The reason why I am not ruling it out though is because I may wish to try a different role in the future to challenge myself.
As for SDETs being looked down upon. Not at all – not at Microsoft. At least with the teams I work on, the developers are very thankful for having test teams as they save their butts on numerous occasions
Especially with something like the Windows Operating System which needs to be tested really well. There may be some stigma in the industry against SDETs because they could be considered “testers” which is incorrect – I like to think of it as SDEs in the test division.
Comment by aliabdin — November 30, 2007 #
Hey Ali,
Thanks for the info.. it really provides a lot of clarity with respect to SDET roles .
What are some of the tasks a fresher can expect in the first couple of months as an SDET ?
Comment by anon — December 4, 2007 #
Hmm – well for me it was reading a hell of a lot of code
For me since I am working on Windows, I also had to learn a lot about the design of Windows, details of the NT kernel, and specifically how file system/storage stack works. This was the main thing.
Besides that some steps I began to take is to understand the way the automation works, start fixing bugs, etc. Thats pretty much the best way to start…Once you gain a better understanding of the test code it will help immensely in understanding the product code, in addition to allowing you to write better tests and add new features to the automation software.
Comment by aliabdin — December 5, 2007 #
Hi Ali,
Don’t you ever felt that it would be kool if you could work on teams that implement a newer file system than to just test it through automation? Is n’t it a greater challenge to implement a file system then just test it?
Thanks.
Best Regards,
Hitesh
Comment by Hitesh Sharma — December 20, 2007 #
I think its rare you will find someone who can get hired right away and start implementing a file system. You gotta learn and start somewhere. Even given that the file system is very large and intricate and has dependencies on many components (e.g. cache management, volume management, filter manager, etc.) – I agree that implementing a new file system is much greater of a challenge than testing an existing one – but testing it actually makes you learn a lot more…you learn the limitations of the file system, and the bugs so it’d help you write a new/better one
Also, at least in WinSE, our work is not only limited to working on existing release – we frequently work and collaborate with the main windows developers with our feedback/ideas/suggestions.
Comment by aliabdin — December 21, 2007 #
Hi,
Thanks a lot for the response
.
I would love to see a blog entry where you describe your day and how it goes in general. Keep blogging, it really helps people like me.
Thanks.
Best Regards,
Hitesh
Comment by Hitesh Sharma — December 21, 2007 #
If I know almost nothing about programming or any of what you mentioned, but am a very computer and math savvy guy (33 years old) who is currently an electrical engineer, how long do you think it would take to learn this stuff and make a career change? And where should I start? It sounds so interesting.
Comment by Robert — January 9, 2008 #
Thats a very tough question
The good thing to know is that lots of people do career changes all the time. I also know people who graduated from something totally unrelated to CS but are working in it full time (I know of at least one colleague here for example who has a BA in Music for example).
In the end though it really depends on what you want to do. There is the easy way – and the hard way to everything. If you want to just program you could just take a few courses and read a few books (and maybe limit yourself to C#/Java) – but I think this is the wrong approach to take.
I think maybe going back to school and getting a CS degree would greatly help…but if you don’t want to go that route, I would at least recommend looking up courses, finding out what books they study, (kinda do your own shadowing of a CS curriculum). Another way where I learned a lot actually is working on open source projects. You get to work on a real product in a team environment with lots of talented people. A cool thing about this approach is that you get to include this experience on your CV.
I also recommend reading a lot of blogs out there on the subject…They can certainly provide you with inside knowledge. For example, on my blog I recommend a few books to read on the SDET topic.
Good luck in your future
Comment by aliabdin — January 9, 2008 #
Great tips, but I have some what of an edge case question.
I have been a black box tester for a while and have not had much luck with the coding aspects of an SDET inteview. Finding a position that touches that middle ground of not having much coding experience and having just enough has been quite daunting.
Could you offer some indication what level of coder an SDET is expected to be at interview? Novice? Intermediate? What C# knowledge goes with those terms?
Any answer would be appreciated!
Comment by Michael — January 29, 2008 #
You article is quite informative. Although my query revolves around two different roles QA and SDET.
Microsoft doesn’t hire people with QA background but what if you have convincing programming skills that you can exibit, can you make a switch from QA to SDET.
Also are you working in redmond or Hyderabad, India
Comment by Prashant — December 26, 2008 #
I have been an SDET at Microsoft for over a year now, so this is my insight. If you have good coding skills, expect it to be a rough but good learning experience. You’ll want to do it for a little while, but only to make you a better programmer and better all around debugging person. Do the SDET thing for no more than 2 years. Then find something different, because if you’re a decent programmer you will be way more appreciated as an SDE.
The plus side is, you could get a lot of neat projects thrown at you that you might not if you were an SDE. The bad part is that no one will give a crap about any coding you did because for the most part they care about the bugs you find. The other crappy part is that you might end up with a team / manager that is close minded as hell and wants to run a squad of monkeys.
Comment by Fooster Barington — March 28, 2009 #
I dont know, being on a squad of monkeys is kinda fun, we fling bug poo at each other all day and scream our loud monkey cries into the night. As far as working in the Land of Milk and Honey (MS) sounds to me like it has turned into a little India. I used to want to work there but now I think this monkey couldnt understand a word anyone says!
Comment by Monkey — June 15, 2009 #
Hi
I am Test Engineer-SDET in MindTree for two years.Nice to hear about the role of SDET.I fully agree with your comments.I have one question “what is difference between QA and SDET?”
Comment by Rajesh Kumar Sahu — July 29, 2009 #