SET是专注于测试的软件工程师。他们是乐于编写测试功能的软件工程师。首先说，SET是开发者，在招聘的时候我们就会说这个工作是100%的编码工作，晋升阶梯中的描述也是如此。当我们面试SET的时候，对于写代码能力的要求跟SWE几近相同，之外我们还会强调SET要懂得如何测试他们自己的代码。换句话说，SWE和SET都要回答编码问题，但是SET要面对更多的测试问题。
你应该猜到了，这个角色很难做，而且造成Google的SET数量很少的原因，可能完全不是因为我们有针对生产率的一套魔法公式，而在于：把我们的工程实践应用到SET技能的人真的很难找。我们优化这项重要的工作并且围绕这些人建立流程。
SET不会参加到前期的设计当中，之所以如此不是我们有一这样的，这是由我们的项目诞生方式来决定的。一个典型的新项目诞生情况就是：员工的20%非正式时间的投入变成了Google自己品牌的项目。Gmail和Chrome OS都是这样在一开始没有自上而下的一个任务指派，但是最终成长为由很多开发和测试工程师组成的团队来共同构建的产品。在这样的一种情况下，一开始的开发是不在乎质量的，其目的在于验证一个概念，或者是专注可扩展性、性能等一些在质量成为问题之前必须正确的东西。简单来说，如果你不能够使你的web service能够有扩展性，那么测试问题就显然不是一个最大问题（扩展性才是）。
一旦确定一个产品能做、要做的时候，那么开发团队就要开始寻求测试的介入了。
一旦确定一个产品能做、要做的时候，那么开发团队就要开始寻求测试的介入了。
关于这个流程你可以这么来想象：某人有了一个想法，首先要对其思考，然后写一下实验代码，去征求其他人的想法，再写代码改进，找其他人一起来做，再写更多的代码，之后他们意识到他们的这个想法非常有价值，进而写更多的代码来实现他们的想法并把实现出来的效果给更多的人看，并收集反馈，这个时候这个项目其实就已经放入了Google的项目数据库了，项目也变成了真正的项目。一个项目在没到达这个阶段前，是不会有测试人员介入的。
所有的项目都会有测试人员么？默认不会。小项目还有那些只对有限的一些用户有用的项目都是由开发那些项目的工程师自己来测试的。其他那些对用户和公司更具风险的才会引起测试的注意。
开发团队任务是向测试人员寻求帮助，向测试人员证明他们的项目是多么的刺激和充满潜力。开发的负责人向测试负责人讲解项目的想法、进展和发布计划，测试负责人则要就“测试工作如何分担”“SWE参与测试”“预期的单元测试级别”“发布中的责任如何分担”等问题展开商讨。SET可以在项目一开始不介入，但是一旦正式立项，在项目如何来实施这个问题上，则有巨大的影响力。
当我说“testing”这个词的时候，我指的不单单是运行代码，覆盖代码路径。测试人员不一定从一开始就介入，但测试（testing）却是（作者的意思是测试其实是无处不在，从项目一开始的各种工作都会与测试有多多少少的联系，比如后面说的提交代码，这里testing如果换成QA可能更有利于国内的一些业内人来理解）。事实上，（请注意）一个开发即便是在提交代码的时候都会感觉到SET的存在。
