软件测试开发工程师【Software Engineers in Test】是软件工程师，专注在测试实现。首先，软件测试开发工程师是开发角色，在招聘和内部晋升资料中被我们奉为100%的编码角色。当在招聘面试软件测试开发工程师的时候，对于编码的要求几乎和对软件开发工程师的要求是一模一样的，而且更强调如何去测试自己写的代码。换句话说，软件开发工程师和软件测试开发工程师都需要回答编码问题，而且软件测试开发工程师会被问到一系列测试相关的问题。
正如你可能想到的，这是一个很难满足的角色。软件测试开发工程师的数量如此之少的最有可能的原因是，事实具备软件测试开发工程师所需技能的人非常难找，而不是我们刻意使用了什么神奇的生产率公式【译注，开发测试比率公式】， 这也是我们适应当前工程实践的一个必然结果。我们还在优化我们的工程实践–这是一个非常重要的任务，并且为所有参与的人构建一些流程。
通常来说，软件测试开发工程师不会在早期设计阶段就介入。不是故意这样做，而是和多数谷歌的产品是如何诞生的有关。一个常见的新产品诞生的场景是这样，已有的谷歌产品的员工会投入20%时间来开始新的产品。Gmail和Chrome OS这2个产品，从一个简单的想法开始，并非正式地由谷歌授权去做的，慢慢地随着时间的推移，越来越多的开发和测试加入进来并把产品发布。在这种情况下，早期的开发要关注的重心并不是质量，更关注提供一些理念，在解决了扩展性和性能的问题之后，再更多地关注质量。如果你创建了一个web service，但是不具有可扩展性时，测试这时候还并不是你最大的问题。
一旦这个产品已经明确未来可以发布的时候，研发团队就开始寻求测试的介入了。
你可以想象这样一个过程，某个人有了一个好主意，他开始思考并写了一些试验性质的代码，从其他人那里获取一些建议然后对这些代码做了改进，并劝说更多的人加入，写了越来越多的代码，然后意识到他们做的事情很重要，通过更多的代码把这个想法变成可以呈现给他人并得到反馈的模型… 这个项目在谷歌的项目库中就创建了，这个项目慢慢地变成了一个真实的项目，测试也只有在项目变成真实的项目之后才会介入进来。
所有真实的项目都有专职的测试人员么？ 默认情况下是没有的。小型项目和只有受限用户使用的项目一般是开发人员自己做测试。其他的一些对个人或者企业用户有潜在风险的项目，测试会介入。
当开发团队寻求测试团队参与并帮助他们时，他们有责任使测试人员相信他们的项目是令人兴奋并充满潜力的。开发总监会给测试总监解释他们的项目、进度、发布计划，一起讨论测试工作如何划分，并就开发需要满足的单元测试水平及开发参与测试工作程度上达成一致，发布流程中开发与测试的责任也需要明确。软件测试开发工程师在项目初期可能不会参与进来，一旦项目变成真实的项目后，测试人员将在软件开发过程中发挥巨大的影响力。
当我说“测试”时，并不是仅仅意味着单纯的检查验证代码路径。测试人员不是从开始就参与进来的，但“测试”却至始至终都有。实际上，一个开发尝试去check in代码的时，测试人员的影响力在这个时刻可能就已经显现出来了。【译，这里指软件测试开发工程师会对开发人员的测试程度做一些要求，开发人员在check in code的时候需要想一下自己是否满足这些要求，这就是测试人员的影响力】。欢迎继续收听并尝试理解我所说的这些东西。
公直
2012/6/28
#p#
英文原文，
How Google Tests Software – Part Six
http://googletesting.blogspot.com/2011/05/how-google-tests-software-part-six.html
Monday, May 02, 2011 12:05 PM
By James Whittaker
The Life of an SET
SETs are Software Engineers in Test. They are software engineers who happen to write testing functionality. First and foremost, SETs are developers and the role is touted as a 100% coding role in our recruiting literature and internal job promotion ladders. When SET candidates are interviewed, the “coding bar” is nearly identical to the SWE role with more emphasis that SETs know how to test the code they create. In other words, both SWEs and SETs answer coding questions. SETs are expected to nail a set of testing questions as well.
As you might imagine, it is a difficult role to fill and it is entirely possible that the low numbers of SETs isn’t because Google has created a magic formula for productivity but more of a result of adapting our engineering practice around the reality that the SET skill set is really hard to find. We optimize on this very important task and build processes around the people who do it.
It is usually the case that SETs are not involved early in the design phase. Their exclusion is not so much purposeful as it is a by-product of how a lot of Google projects are born. A common scenario for new project creation is that some informal 20% effort takes a life of its own as an actual Google branded product. Gmail and Chrome OS are both projects that started out as ideas that were not formally mandated by Google but over time grew into shipping products with teams of developers and testers working on them. In such cases early development is not about quality, it is about proving out a concept and working on things like scale and performance that must be right before quality could even be an issue. If you can’t build a web service that scales, testing is not your biggest problem!
Once it is clear that a product can and will be built and shipped, that’s when the development team seeks out test involvement.
You can imagine a process like this: someone has an idea, they think about it, write experimental code, seek out opinions of others, write some more code, get others involved, write even more code, realize they are onto something important, write more code to mold the idea into something that they can present to others to get feedback … somewhere in all this an actual project is created in Google’s project database and the project becomes real. Testers don’t get involved until it becomes real.
Do all real projects get testers? Not by default. Smaller projects and those meant for limited users often get tested exclusively by the people who build it. Others that are riskier to our users or the enterprise (much more about risk later) get testing attention.
The onus is on the development teams to solicit help from testers and convince them that their project is exciting and full of potential. Dev Directors explain their project, progress and ship schedule to Test Directors who then discuss how the testing burden is to be shared and agree on things like SWE involvement in testing, expected unit testing levels and how the duties of the release process are going to be shared. SETs may not be involved at project inception, but once the project becomes real we have vast influence over how it is to be executed.
And when I say “testing” I don’t just mean exercising code paths. Testers might not be involved from the beginning … but testing is. In fact, an SET’s impact is felt even before a developer manages to check code into the build. Stay tuned to understand what I am talking about.
