测试工程师的职责重点在于评估对用户的影响以及软件产品整体目标上的风险。
1.为了成为一等公民，TE必须首先是工程师的一部分。Google的TE综合了开发者仰慕的技术能力和以用户为中心检查软件质量而对开发者产生一定制约的能力。
1.在研发的早期阶段，功能还在不断变化，最终功能列表和范畴还没有确定，TE通常没有太多的工作可做。
2.TE在进入产品时，需要考虑以下一些问题：
当前软件的薄弱点在哪里？有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其它方面的问题？主要用户场景是否功能正常？对于全世界不同国家的用户都是这样吗？这个产品能与其他产品（软件和硬件）互操作吗？当发生问题的时候，是否容易诊断问题所在？3.TE的根本使命是保护用户和业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、功能bug、安全和隐私等问题的困扰。
4.理想情况下，测试计划应当在项目执行中发挥核心作用，应当在软件的整个生命周期中持续有效：随着代码库的更新而更新，时刻代表最新的产品功能，而不是停留在项目开始阶段时的样子。
5.关于风险：
Google TE对风险最高的领域负有个人责任，即使他们可以协调其他TE、使用各种工具，最终的责任仍然是他们自己的。TE需要自己编写一些测试用例，还是需要请SET或SWE来编写分析每个高风险的特质---能力对相关的bug，保证回归测试用例存在。bug倾向于在代码发生变更时重现。高风险组件的每个bug都应该有一个回归测试用例与之对应。仔细思索高风险的区域，咨询可能的回滚和恢复机制。通过设想最坏情况并与其他工程师讨论，发现所有可能对用户产生影响的问题。实验并确定这些场景成为现实的可能性。经常高呼狼来了的TE，其可信度会下降。所以，减少过分反应和大惊小怪是很重要的，除非问题涉及那些真实存在的、现有测试尚未缓解的高风险场景。引入尽可能多的相关各方。如果以上措施皆不凑效，某个高风险的组件仍然处于测试不足的状态，经常出问题，那就得非常努力地去游说相关同事。这正是一个把风险分析的概念解释给项目成员、提现TE价值的机会。6.测试用例的生命周期
7.bug的生命周期
8.测试用例进入维护模式前需要考虑：
撤离之前，把困难的问题解决掉，而不是轻易放过。即使一个小型的、负责端到端测试的自动化测试集，也会以近乎为零的成本提供长期的质量保证。如果没有，一定要建立一个这样的自动化测试集留下一份how-to文档，以便公司的任何人都可以运行你的测试集，这也会减少你在将来繁忙时还被突然打扰的可能性确保有一个问题解决通道，愿意承担一些责任时刻准备着返回到你曾今工作的项目里帮忙，这堆产品、团队和用户都有益1.你如何参与一个新项目呢？你首先会提出哪些问题、做哪些事情？
对于一个新项目，我首先要站在用户的角度了解这个产品。有可能的话，我会作为一个用户，以自己的账户和个人数据去使用产品。我努力使自己经历完整的用户体验。一旦有自己的真实数据在里面，你对一个产品的期待会彻底改变。在具备了用户心态之后，我会做下面的一些事情。
从头到尾的理解产品。不管是整体的设计文档，还是主要功能的设计文档，我都会去看。只要有文档，我就看。在消化了这些文档之后，我开始关注项目的状态，特别是质量状态。我会去了解bug数量、问题的分组方式、已经报告的bug类型、最长时间未处理的bug、最近一些bug的类型等，我还会看一下发现--修复比例。2.身为TE，在你的工作中如何代表用户呢？
我把自己变成用户，就这么简。我认为，除非能以某种方式将自己置于用户的视角，否则就不可能真正有效地对一个应用进行测试。这就是为什么测试远比检查一个版本是否可用要复杂得多的原因；它包括应用的直观性、行业标准等各方面的反馈。换句话说，测试要清楚地指出当做之事。
3.对于你的工作，开发是怎么看待的？如果他们不认可测试的价值，那你又该怎么办？
开发经常会低估我的工作，知道我们在一起工作了几个月之后，他们才会改变想法。我在完成了上述工作之后，将被邀请整个团队开会，介绍一下我设定的测试流程。这种面对面的交流真的很重要，我可以利用这个机会让他们看到我是多么认真严肃地看待他们的应用。结果是一大堆的问题和意见交换。我得到了好的反馈，而他们确信自己有了得力帮手。在我介绍了整个流程，以及我所做的变化、更新和改进之后，所有对测试价值的怀疑通常就会烟消云散了。
4.你的工作如何影响一个产品的发布决定呢？
我会从对用户产生影响的角度来说明为什么一个功能不能上线或整个发布都不能上线。
5.关于TE这个角色，你最喜欢的是什么？
我真的喜欢这种技能带来的灵活性。这个角色是技术性的，但同时也是面向用户的。有什么项目不需要我这样的人呢？我可以给这么多不同类型的项目带来价值。团队在推出一个产品或新功能时难免感到提心吊胆，而我能带给他们镇定和信心，这使我感到自己是一种正面、有益的力量。
1.关于web、Flash以及数据驱动的web服务器，你对其他测试人员有哪些建议？
不管是测试框架还是测试用例都以简单为要，随着项目的开展再迭代的涉及。不要试图事先解决所有问题。要敢于扔掉过时的东西。如果测试或者自动化过于难以维护，不如放弃它并试着去实现更有韧性、更好的东西。密切关注一段时间维护和排错的成本。遵守70-20-10法则：小型的用来验证单个类或功能的单元测试占70%，中型的用来验证一个或多个应用模块之间集成的测试占20%，大型的高级别的用来验证完整应用的测试（一般称为系统测试和端到端测试）占10%。
