Question:

描述测试开发工程师在整个业务研发价值链的作用乃至将来的发展方向,加上朝着这样高效能团队演进的过程和计划

Answer:

测试开发工程师(Software Test Engineer),下面简称SET。

SET应参与开发过程改进质量

SET也是开发角色，和软件开发是合作伙伴关系，关注产品/平台的质量提升和测试覆盖率的增加，日常需要参与产品/平台的设计评审，强调预防行为而不是检测。
SET的重心在代码的可测试性和通用测试基础框架上。为了增加代码的可测试性，甚至会对代码进行重构，以及判断是否需要新增testing hook（为测试新增的接口，显示系统内部状态），提供程序结构和代码风格建议给开发人员。SET可以参与开发的代码评审。
为了高效的进行测试开发，应建立一些公共库/共享代码（可复用性大于功能复杂性和设计巧妙性）。提供比较多的test harness，test infrastructure, mock and fake供软件开发岗/测试开发岗使用。测试和开发应采用相同的语言。
另外，只有能加速开发过程的自动化测试才有意义，测试不应拖慢开发的速度。

自动化测试开发

试图自动化所有端到端的测试用例，是一个常见的错误。
自动化投入越多，维护成本越大。自动化计划，应该规模更小，目的性更强，20%的用例覆盖80%使用场景的优先自动化。
端到端的自动化测试投入过度，会把产品特定功能绑定在一起，产品稳定之前都不会特别有用。SET应该投入到提高质量，而不是维护不稳定的测试套件上。
SET应维护着不同测试类型之间的健康比例，经验法则：70%是小型；20%是中型；10%是大型。如果面向用户，集成度高，用户接口复杂，增加中大型测试比例;
基础平台或面向数据，增加小型测试比例。
自动化测试用例应能以随机顺序执行用例（任意顺序也意味着可以并发），未来可以使用依赖分析技术来优化，做到一个代码的变更只运行所在模块的测试用例。

增强开发人员做测试的文化

让测试认证变成一个富有声望的事情，从１到5级，有勋章可以炫耀。

• 级别1：基本操作，还有去除所有非确定性测试（结果不确定的测试），挑选冒烟测试；
• 级别2：提高增量覆盖率
• 级别3：测试新增代码
• 级别4：测试历史遗留代码（针对可测试性做重构）
• 级别5：更高的覆盖率，每个缺陷对应增加测试用例

(如果Coding可以做到测试资源集中管理，再分发到部门/项目组，可以反过来约束开发团队：
团队的测试认证级别代表提高测试的重视程度，是测试团队决定是否投入有限测试资源的重要参考指标。通过这种方式倒逼开发团队重视测试实践，因为必须重视测试实践，才能获得测试资源）

SET的横向影响

SET先从本部门做好，如果做出成绩，可以允许项目组/部门间的借调，可以保持新鲜感，也能方便好的想法快速蔓延。
这样SET也会有一个很大的优势，就是产品方面的宽广视野，也很适合审核初期阶段的设计文档。

SET的未来

目前存在软件开发岗和测试开发岗，未来应只有软件开发岗，目标就是将测试开发岗做没有。
测试代码变成一等公民，全部由软件开发岗编写。
软件开发团队里的新成员负责测试开发，因为必须学习产品的所有东西，包括内部设计，是一个非常理想的热身项目。