转：What does an SDET do?

 

这是一个MS SDET写的博客，大概是个女孩子吧，在文章后面还热心的回答了很多提问。

 

http://aliabdin.wordpress.com/2007/03/31/what-does-an-sdet-do/

 

What does an SDET do?

March 31, 2007 at 7:49 pm | In Microsoft, Software development | 

I’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!