相比SWE和SET，TE在Google是一类新职位。因此，这个职位的角色定义还在进行中。当前Google的这代TE正在为这个职位开辟一条道路，这样就能更好的指导后面招聘进来的TE来开展工作。我们这里描述的是在Google新兴起来的一个最好过程（It is the process that is emerging as the best within Google that we present here）。
并不是每个项目都需要TE。那些在产品初期的实验性尝试，没有良好定义的任务或用户场景的项目势必不会引起很TE的注意。如果一个产品看起来没什么希望（作为一个概念他不能通过审核）或者尚未能吸引用户注意或者没有清晰的功能定义（原文是have a well defined set of features，怀疑是作者落下了not，从上下文判断应该是not have a well defined set of features），测试工作就应该是开发他的人自己来做。
即便对于一个确定要对外发布的产品，TE在开发阶段的初期也没什么事情可做，因为在这些阶段功能在不断变动，最终的功能和边界也不确定。在测试方面太早的投入过多就会导致很多工作被丢弃（因为产品的功能可能后来就变了）。同理，一开始做测试计划需要的TE数量比后期做探索性测试TE数量少很多，因为，到了后期产品几近成型，这个时候寻找遗漏bug显得非常紧急。
在一个项目中配备TE跟风险和ROI息息相关。对于客户和企业来说这意味着要花更多的测试精力同时需要更多TE。但是这种努力需要和回报成比例。我们需要正确数量的TE在正确的时间并起到正确的作用。
一旦介入，TE并不是一切从头开始来。因为已经有SWE和SET做了大量的测试工程化和面向质量的工作，这些工作都是TE后续工作的基础。TE的初期介入要做的事情有：
- 软件什么地方最薄弱？
- 安全、隐私、性能、可靠性方面都有哪些考量？
- 对于国际的各种用户，是不是所有的首要用户场景都能按照既定的方式工作？
- 产品会和其他产品（包括硬件和软件）交互吗？
- 一旦出了问题，问题的诊断是不是容易做到？
所有的这些都在质疑要发布软件的风险轮廓。TE并不需要亲自做所有的这些工作，但是他要确保这些事情都做了，并利用别人的工作来评估是不是还有更多需要做的事情。总的来说，TE对企业的价值体现在他保护用户和公司免受一系列问题的侵扰，比如坏的设计、令人困惑的UI、功能bug、安全和隐私问题等。在Google，TE是一个团队中唯一个全职的从整体上来关注产品和服务弱点的人。因此，TE的职业路线相比SET来说远没有规则和格式可循。在项目的任何阶段都有可能需要TE的协助，从创意阶段到好几个版本发布，甚至是监视一些过时的、封存的项目。通常，一个TE会同时服务于多个项目，特别是那些有特殊技术（比如安全）TE。
显然，不同项目中TE要做的事情可能差别蛮大的。有些TE要花大量的时间写代码，有点像SET，只不过重心是关注终端用户的使用场景。还有些TE针对现有的代码和设计从中寻找故障失败模式和导致故障的原因，这种情况下，TE可能会修改代码但是不会从头写。TE在做测试计划的时候必须更系统、全面，并在真正使用（系统）和系统经验方面兼顾完整性。TE擅长处理需求中的模糊性，并且善于推理和表达逻辑问题。
成功的TE在敏感的、有时候个性很强开发、产品团队之间游走过程中完整所有任务。每当他发现漏洞，TE高兴的攻破系统，并驱动SWE、PM、SET去解决这些问题。
这样的一个职位描述可能让他的前景有点吓人，他需要各种知识的融合包括技术方面的、领导力方面的、产品理解方面的，如果没有合适的指导，这个职位很可能会失败。但在Google，强大的TE社区已经出现来对付这种情况。在所有的职位中，TE可能是最注重支持（peer supported）的这么一个角色，做好TE这个职位需要的洞察力和领导力通常意味着很多的测试经理都是从TE这个职位里走出来的。
Google的TE工作的流动性掩盖了各种程式化的介入过程（言外之意就是TE的工作很灵活不确定，原文是：belies any prescriptive process for engagement）。TE可以在任何时间点介入项目，并且必须要迅速的评估项目的状态、代码、设计和用户，还要确定什么是首要关注的东西。如果项目是刚开始启动，测试计划通常首要考虑的事情。有的时候TE会在项目的末尾阶段被拉来评估项目是不是适合发布，或者一个早期的Beta版被放出的话会不会有问题。如果TE来到的是一个新应用或者是一个他之前没有任何经验的应用，他们就会从一些探索性测试开始做起，基本没有什么规划。还有的情况是项目很久没有发布了仅需要一些（安全）修复，或者界面交互的调整，这对TE来说就需要一些不同的策略。总之一句话，在Google中TE的工作没有定式可循。
