当TE进入产品的时候，并不需要从零开始。SWE和SET已经在测试技术和质量方面做了大量的工作，可以作为TE的起点。TE在进入产品时，需要考虑以下一些问题。
- 当前软件的薄弱点在哪里？
- 有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题？
- 主要用户场景是否功能正常？对于全世界不同国家的用户都是这样么？
- 这个产品能与其他产品（软件和硬件）互操作吗？
- 当发生问题的时候，是否容易诊断问题所在？
当然这只是一个不完全列表。所有这些加起来，构成发布待评估软件的风险概要。TE并不需要自己去解决所有这些问题，但必须保证这些问题被解决掉，他们可以请其他人帮忙评估还有多少工作需要去做。TE的根本使命是保护用户和业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、功能bug、安全和隐私等问题的困扰。在Google，TE是一个团队中全职地负责从整体角度发现产品或服务弱点的唯一角色。因此，与SET相比，TE的工作并不是那么确定。TE会介入项目的各个阶段：从产品的构思阶段到第8个版本，甚至是照看一个已经下线的项目。一个TE同时参与几个项目也很常见，尤其是那些具备安全、隐私或全球化等专门技能的TE。
显然，在不同的项目中，TE的工作内容也会有较大的不同。一些TE会在编码方面投入较多的时间，但主要是写中到大型的测试（如端到端的用户场景）而非小型测试。其他一些TE会检查代码和系统设计以确定失效模式，并寻找导致失效的错误路径。在这种情况下，TE可能会去修改代码，但这与从头编写代码是不同的。TE在测试计划及测试完整性上必须更加系统和周密，重点在真实用户的使用方式和系统级别的体验上。TE擅长发现需求中的模糊之处，分析沟通不明确的问题。
成功的TE游走于这些微妙且敏感的地方，有时候还要与个性很强的开发和产品人员打交道。一旦找到薄弱点，TE就会通过测试使软件出错，然后与开发、产品、SET一起推动解决这些bug。TE通常是团队里最出名的人，因为他们需要与各种角色沟通。
考虑到技术能力、领导力、深刻理解产品的能力等多方面的要求，TE的职位描述有点吓人。事实上，如果没有合适的指导，很多人难以胜任这个工作。幸运的是，在Google，一个由TE组成的强大社区的出现解决了这个问题。在所有的工种里，TE可能是在互帮互助方面做得最好的了。这个角色需要敏锐的洞察力和领导力，因此很多Google的高级测试经理们都来自于TE。
这个角色需要敏锐的洞察力和领导力，因此很多Google的高级测试经理们都来自于TE。
TE的工作经常需要去打破常规流程。TE可以在任何时间进入项目，必须迅速评估项目、代码、设计和用户的当前状态，然后决定首要的关注点。如果项目刚刚开始，测试计划是第一优先级。有时，TE在产品后期被拉进来帮助评估项目是否可以发布，或者在beta版本发布之前确认还有哪些主要的问题。当TE进入了一个新被收购的应用或缺少相关应用经验的时候，他们经常会先去做一些不怎么需要计划的探索式测试。有时，项目已经很久没有发布了，只是需要去做一些修饰、安全补丁或界面更新，这需要迥然不同的方法。
在Google，TE需要在不同的项目中做不同的事情。我们经常将TE的工作描述为"从中间开始（starting in the middle）"，因为TE必须保持足够的灵活，能够迅速融入一个产品团队的文化和现状。如果做测试计划已经来不及了，那就干脆不做了。如果一个项目最需要的是测试，那就做一个简单够用的指导性计划。一些测试教条所倡导的从头就介入的模式，在Google并不适用。
下面是我们关于TE职责的一般性描述。
- 测试计划和风险分析；
- 评审需求、设计、代码和测试；
- 探索式测试；
- 用户场景；
- 编写测试用例；
- 执行测试用例；
- 众包（译注：crowdsourcing，是互联网带来的新的生产组织形式。一个公司或机构把过去由员工执行的工作任务，以自由自愿的形式外包给非特定的（通常是大型的）大众网络的做法）；
- 使用统计；
- 用户反馈。
当然，能够最好的完成这些任务的，是那些有很强的人格魅力和优秀的沟通技巧的测试工程师。
