《Google 软件测试之道》是 2013 年出版的，书中记录的也都是截止当时的 Google 软件测试的现状，如果和国内目前的情况相比较的话，Google 不仅仅是走在了前列，而且是远远看不到边的前列。
我在上篇文章中有提到 Google 当时对于测试团队的定位，已经是上升到「工程生产力」部门的高度了，而对应的，随着团队职责的不断演化，团队成员的职责也进行了对应的转变。
Google 测试团队的职级汇报关系是：TE（Test Engineer，测试工程师） 和 SET（Software Engineer in Test，软件测试开发工程师） -> 测试工程经理 -> 测试总监 -> 高级总监 -> CEO。
今天我把书中提到的两个最主要的角色 SET 和 TE，分别提取了他们具体的工作职责，希望藉此可以作为我们努力的目标。
Google中的SET
SET 的部分职责是在单元测试方面给予开发人员支持，另一部分职责是为开发人员提供测试框架，以方便他们编写中小型测试，用以进行更多质量相关的测试工作。
SET 是 100% 的编码角色，作为测试的开发工程师和功能的开发工程师处于同等的地位。
一个好的 SET 具有宽广的整体产品视野，而且在产品的整个生命周期里对产品及功能特性都有充分的理解。
一个好的 SET 在项目早期参与项目时，会协助项目形成良好的文档、不错的可测试性、运行稳定的自动化测试、清晰的代码提交流程。
通常来说，代码复用和模块交互方面的设计会由 SET 来做，而不是 SWE（Software Engineer）。
SET 在审阅设计文档时，预期要关注的要点有：完整性、正确性、一致性、设计、接口与协议、测试。
SET 是第一个实现所有接口和协议的人，SET 针对各个模块的依赖提供了 mock 或 fake 的实现。
SET 的第一要务是可测试性，SET 需要提供程序结构和代码风格方面的建议给开发人员，这样开发人员可以更好地做单元测试，同时提供测试框架方面的建议，让开发人员可以在这些框架基础上自己写测试。
SET的面试，重点在考察候选人如何思索问题的解决方案，而不是解决问题方案本身的实现上有多高雅。
Google中的TE
TE 负责从用户的角度来思考质量方面的各种问题。从开发角度来说，他们编写用户使用场景方面的自动化用例代码，从产品角度来说，他们评估整体测试覆盖度，并验证其他工程师角色在测试方面合作的有效性。
TE 以对某种特定的产品最合适的方式发现软件中风险最大的地方并尝试减少或消除它。
TE 的根本使命是保护用户和业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、功能 bug、安全和隐私等问题的困扰。
TE 是团队中全职地负责从整体角度发现产品或服务弱点的唯一角色。
TE 的主要职责包括但不限于：测试计划和风险分析、评审需求、设计、代码和测试、探索式测试、用户场景、编写测试用例、执行测试用例、众包、使用统计、用户反馈。
TE 的招聘要求：
1、测试过程中会关注需求确认、会从用户角度考虑问题、会通过逻辑关联提高用例覆盖率的人；
2、具备处理模糊性、反驳糟糕想法的能力，对需求合理性提出质疑；
3、有好奇心并充满激情。
总之，SET 负责可测试性和测试自动化体系的长期有效性。TE 的重点在于评估对用户的影响以及软件产品整体目标上的风险。
对于TE，某些人可能觉得比较虚，还是SET经常写code实在。国内的测试团队，基本上把SET的工作和TE的工作合二为一，放在一个人的身上，然而SET和TE的技术和要求是不一样的，我们测试团队的测试开发工程师都能很好的具备SET和TE的能力吗，我们真正的测试工作重心到底是什么呢？我们的测试开发工程师都能在产品的测试过程中发挥这么多的作用吗？大家可以自己思考下。