Advanced QA Engineering

SDET stands for Software Development Engineer in Test (or Software Design Engineer in Test). I believe this title was originated at Microsoft (but have not researched this). It is also used at Amazon.com and Google.

As the Testing Ecosystem is evolving there is an ever reducing demand for simple “Manual Tester”. In the recent times, the trend is for the software developer who creates the code for the software, and then have a tester who tests the software through white-box testing. These days, 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 .

Following are the important aspects of being an SDET:

Developing new testsThis 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 SDETs 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.

Excellent debugging skills Debugging code can be a huge field by itself and to be a good SDET one needs good debugging skills. SDETs 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 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 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.

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.