通过

I am Test

  • 项目

There is a funny thing that happens when people mention the terms “test”, “tester”, or “quality assurance” in the computer programming industry. Groans can be heard about laborious, manual point-and-click activities. A cutting remark is almost always heard that insinuates a person who performs testing is a “click monkey.” Well,  I work in test at Microsoft, and I’m a hard-core software developer.
At other companies, “quality assurance” and “test” may mean different things, but at Microsoft the Software Development Engineer in Test (SDET) is a regular developer. In my group at Microsoft (GPD-E, a European R&D hub based in Dublin, Ireland), we expect the Software Development Engineers (SDE) to make sure their code does what it’s supposed to do in trivial cases, either by producing unit tests or by performing some manual verification.

Then we call in the SDETs. SDETs are Microsoft’s answer to the question of how to achieve and maintain quality for our customers when shipping software and services that scale to tens of millions of users. The SDET is tasked with both product quality and team productivity. The SDET uses their development skills to build systems that advocate for the customer in all aspects of a project, from inception through to shipping. SDETs act as a key interface between customers and the engineering team and are the real “last line of defense” before a product goes out the door. The SDET has accountability for ensuring the product is ready to ship or if it needs more time, and he or she is responsible for blowing the whistle if something looks wrong.

As SDETs, we spend most of our time writing code for automation frameworks and testing tools, whether running on a mobile phone, a virtual PC image, or across a data center of thousands of servers. We develop tools that improve productivity and uncover bugs; many of these tools are highly sophisticated and widely utilized both inside and outside of Microsoft. For example, we develop tests that evaluate system security, performance, resilience, functionality, standards compliance, and accessibility, to name a few broad types. Under the banner of productivity, for instance, we have written a tool for improving CSS cohesion and manageability for serving to mobile devices. Of course, we sometimes do need to rely on manual testing to evaluate for things like usability or interoperability corner cases. In those cases, we often rely on the input and assistance from the rest of the engineering team, taking advantage of Microsoft’s quality-conscious culture.

I’m proud to say that at Microsoft, SDETs solve the big problems of ensuring our products work for all of our customers and our development and quality processes are as efficient as possible. So, the next time you consider what it means to “be in test” or “be a tester” and whether that’s a good job for a software developer, think about Microsoft and the SDET role.

Comments