在谷歌，为了成为一等公民，TE必须首先是工程师的一部分。谷歌的TE综合了开发者仰慕的技术能力和以用户为中心检查软件质量而对开发者产生一定制约的能力。

TE的职位描述是最难定义的，因为其职责范围很广而且不确定。人们期望TE在各种各样的构建物的完成、集成、最终形成完整的产品过程中监督所有产物的质量。因此，大多数的TE都会从事一些基础技术层的、需要另外一种视角和较强的专业技术能力的工作。这一切都与风险相关：TE以对某种特定的产品最合适的方式发现软件中风险最大的地方并尝试减少或消除它。如果需要做SET的工作，TE就去做；如果需要代码审查，那就只管去做；如果缺少测试工具，那就花一些时间在上面。

接下来，同一个人还会在项目的其他时段去领导探索性测试，或者管理内部试用版的测试工作。在不同的项目阶段，SET和TE的重点不同，早期的工作涉及更多的面向SET的任务，而项目后期才是面向TE的任务。还有一些情况是TE的个人选择，他们可以在不同的角色间切换。但凡事没有绝对，我们在下面的描述，只是代表了理想的情况，测试工程师的工作范围。

在研发的早期阶段，功能还在不断变化，最终功能列表和范畴还没有确定，TE通常没有太多的工作可做。我们需要在正确的实践，投入正确数量的TE，并带来足够的价值。

当TE进入产品的时候，并不需要从零开始。SWE和SET已经在测试技术和质量方面做了大量的工作，可以作为TE的起点。TE在进入产品时，需要考虑以下一些问题：

当前软件的薄弱点在哪里？

有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题？

主要用户场景是否功能正常？对于全世界不同国家的用户都是这样吗？

这个产品能与其他产品（软件和硬件）互操作吗？

当发生问题的时候，是否容易诊断问题所在？

这是一个不完全列表，所有这些加起来，构成发布待评估软件的风险概要。TE并不需要自己去解决所有这些问题，但必须保证这些问题被解决掉，他们可以请其他人帮忙评估还有多少工作需要去做。TE的根本使命是保护用户和业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、功能bug、安全和隐私等问题的困扰。在谷歌，TE是一个团队中全职地负责从整体角度发现产品或服务弱点的唯一角色。因此，与SET相比，TE的工作并不是那么确定。TE会接入项目的各个阶段：从产品的构思阶段到第八个版本，甚至是照看一个已经下线的项目。一个TE同时参与几个项目也很常见，尤其是那些具备安全、隐私或全球化等专门技能的TE。

显然，在不同的项目中，TE的工作内容也会有较大的不同。一些TE会在编码方面投入较多的时间，但主要是写中到大型的测试（如端到端的用户场景）而非小型测试。其他一些TE会检查代码和系统设计以确定失效模式，并寻找导致失效的错误路径。在这种情况下，TE可能会去修改代码，但这与从头编写代码是不同的。TE在测试计划及测试完整性上必须更加系统和周密，重点在真实用户的使用方式和系统级别的体验上。TE擅长发现需求中的模糊之处，分析沟通不明确的问题。

成功的TE游走于这些微妙且敏感的地方，有时候还要与个性很强的开发和产品人员打交道。一旦找到薄弱点，TE就会通过测试使软件出错，然后与开发、产品、SET一起推动解决这些bug。TE通常是团队里最出名的人，因为他们需要与各种角色沟通。

考虑到技术能力、领导力、深刻理解产品的能力等多方面的要求，TE的职位描述有点吓人。事实上，如果没有合适的指导，很多人难以胜任这个工作。幸运的是，在谷歌，一个由TE组成的强大社区的出现解决了这个问题。在所有的工种里，TE可能是在互帮互助方面做得最好的了。这个角色需要敏锐的洞察力和领导力，因此很多谷歌的高级测试经理们都来自于TE。

TE的工作经常需要去打破常规流程。TE可以在任何时间进入项目，必须迅速评估项目、代码、设计和用户的当前状态，然后决定首要的关注点。如果项目刚开始，测试计划是第一优先级。有时，TE在产品后期被拉进来帮助评估项目是否可以发布，或者在beta版本发布之前确认还有哪些主要的问题。当TE进入了一个新被收购的应用或缺失相关应用经验的时候，他们经常会先去做一些不怎么需要计划的探索性测试。有时，项目已经很久没有发布了，只是需要去做一些修饰、安全补丁或界面更新，这需要迥然不同的方法。

在谷歌，TE需要在不同的项目中做不同的事情。我们经常将TE的工作描述为“从中间开始”，因为TE必须保持足够的灵活，能够迅速融入一个产品团队的文化和现状。如果测试计划已经来不及了，那就干脆不做了。如果一个项目最重要的是测试，那就做一个简单够用的指导性计划。一些测试教条所倡导的从头就介入的模式，在谷歌并不适用。

TE的一般职责包括：

测试计划和风险分析；

评审需求、设计、代码和测试；

探索性测试；

用户场景；

编写测试用例；

执行测试用例；

众包；

使用统计；

用户反馈。