前言
三年前的一天，朱少民遇到思科的同事，问了下他现在软件开发采用的是什么模式？他回答：“已全面实施敏捷开发模式了，有些团队都没有测试人员，测试都是开发人员自己做。”朱少民接着问，那怎么知道开发人员测试做得如何？效果怎样？他回答：“这个不知道，我们相信他们，他们也承诺对自己的代码质量负责任。”
让开发做更多的测试，没错，这就是我们常说的测试左移，但还是需要了解开发怎么做的测试，能不能达到专业的测试水平？一方面就是第6讲所说的，像 Google 公司那样对整个研发团队的测试能力进行认证。但是，如果认证的结果显示整个研发团队的测试能力比较低、研发达不到要求，怎么办？这就是本讲所要讨论的主题，设置一个“Test Owner（TO）——测试责任人”角色来帮助团队提高测试能力，并完成过渡时期测试质量的控制和管理工作，包括承担起测试计划制定、测试用例的评审等责任。
冰冻三尺非一日之寒
为什么要设置这样一个角色呢？除了上面的原因之外，我们团队还需要一个相对比较长的时期，以完成从传统测试向敏捷测试的平滑过渡，从传统的研发团队转型成敏捷团队，有时需要很长的时间，而且企业领导必须有决心去支持团队转型，也需要请教练来辅助团队如何具体实施新的开发模式。
大概20年前，朱少民在WebEx 公司参加软件产品研发的时候，那时候的产品经理不属于研发团队，而是属于产品市场（product marketing）,这个部门和研发部门不同，它更向财务人事部门那样，直接隶属公司管理。而研发部门，包括开发，测试、项目经理等，则根据具体的业务领域分为独立的BU (Bussiness unit)，这个时候，产品部门和研发之间的那堵墙特别厚，如图1所示的最左边的那种结构，产品经理把需求从墙那边扔过来，扔到研发这边，研发人员接到需求，按照需求进行设计、编码和测试。10年前模式开始有好转，开始往敏捷模式转型。
图一
以Scrum为例，设立Product owner(产品责任人角色)，产品设计和研发开始在一个团队，迭代周期也从之前的半年、一年缩短至一个月、一周。最近几年开始慢慢减少测试人员，有些团队干脆没有测试人员，让开发做测试，整个团队对测试、对质量负责。这个出发点是对的，也特别符合敏捷测试的思维方式。但一口吃不成胖子，不能急于求成，就像上面把产品定义和设计移到内部，需要设置PO角色，所以，当我们想彻底实现从传统测试向敏捷测试转型的过程中，也需要设置TO角色，如图中下部的角色。
从传统开发模型向敏捷模式转型，分为两种情况：
- 将测试人员和开发人员等整合成一个全职能的特性团队，保留专职的测试人员，里面设置TO角色，而不应该设置测试经理角色（敏捷组织是自我管理的组织），会议召集或清理障碍等管理工作可以由Scrum Master来做。
- 经过一个过度阶段，再彻底实现开发与测试的融合，没有专职的测试人员，都成为软件工程师，如图一所示。
多数团队不是google
民间俗语：一个和尚挑水喝，两个和尚抬水喝，三个和尚没水喝。当我们推行”质量由团队负责“这样的理念时，从我国国情来看，多数团队的软件产品质量可能就没有人负责，虽然极其优秀的团队没有问题。当国内某些团队直接照搬Google公司的流程喝实践时，有识人士就曾发言特别提醒：你公司不是google，你公司还不是google,你公司本来就不是google。所以，对于大多数团队来说，测试还是需要责任人，需要owner,比较切实可行的实践是需要设置TO 这个角色，这个角色对测试计划、测试过程和测试结果负责，虽然对质量负责。即使在大多数情况下，我们也是认定：”测试是构建出来的“，如果需要有人对质量负责，也可以设置Quality Owner这样的角色，负责促进优秀质量文化的形成，流程内审和改进，推行全过程的质量管理等。大多数公司没有QA这样的角色，这时，测试人员或多或少要承担QA部分责任，这就是为什么许多美国公司的测试工程师被称为QA工程师。
敏捷测试提倡”预防缺陷 胜于发现缺陷“，QA主要责任就是通过定义好的流程、好的规范等来预防缺陷，而测试的主要责任则是发现缺陷。只是平时我们不会注意区分QA和测试，所以还可以说”敏捷测试提倡:预防缺陷胜于发现缺陷“，本来应该说”敏捷质量管理提倡：预防缺陷胜于发现缺陷“。
Test Owner(TO)是以敏捷中最流行的Scrum 方式来定义这个角色的名字，也可以称为”测试教练（Testing Coach，TC）“ ”测试顾问（Testing Consultant,TC）“ 或者QA ,叫什么不重要，重要的是这个角色要承担哪些责任。
TO角色的责任和具体实践
制定软件产品研发的迭代测试计划
虽然是一个简单的计划，也是一个动态的过程，但计划依旧很有价值，同时指导这个迭代的测试过程，所以需要有一个人来负责计划的起草、召集评审会议等，还包括测试范围分析、列出测试项、定义优先级、识别测试风险、制定测试策略、估算工作量等工作。
协调测试计划的执行
包括收集团队的反馈。洞察新的测试风险，对计划进行优化或调整，协调测试任务或测试资源等
促进提高软件的可测试性
参与前期需求分析和定义验收标准，更好地保证需求、设计、代码等的可测试性，可能的话，领导团队还可制定测试性规范或实施指南。
指导团队成员开展测试工作
不限于用户故事的验证，系统级别的测试，也包括单元测试、集成测试；不限于动态测试，还包括需求评审、设计评审和代码评审等；团队成员若在测试工作中有疑问，有困难，则可以向这个角色咨询，以得到她/他的帮助。
承担部分QA责任
例如领导团队制定评审流程和规范，帮助开发人员消除不规范行为；不断寻求机会以提高需求、设计、代码的质量和可重复性，积极影响开发的质量意识；和团队一起做好缺陷跟踪、缺陷分析和缺陷预防等工作，在整个开发周期中进行质量跟踪、持续改进质量。
其他责任
例如指导团队进行测试基础设施，自动化测试框架等工作，为团队提供相应的内部测试培训，帮助团队提高整体测试计划和知识的等
根据团队大小、开发人员的测试能力和其他实际情况，TO可以由一个人担任，也可以由多个人担任，或者2-3个团队共同拥有一个TO，一般由公司内部测试专家、原来担任过测试经理的人员来担任比较合适（熟悉测试流程、测试方法），之前负责过测试项目或项目中测试的部分，指定过测试计划，管理过测试过程，也管理过团队，由经验和能力履行上述TO 责任。如果没有测试经理，也可以由测试架构师或者资深的测试工程师来担任，如果能力比较大，还可以由测试经理和测试架构师联合担任。
Master Test Owner
当一个产品线需要多个同时并行的组件开发项目来完成时，或者开发一个系统需要多个子系统的开发同时并行时，这时就是我们常说的大估摸系统开发，不是由一个敏捷团队就能完成的，而是由多个敏捷团队协作完成，在项目管理中，项目集包含多个项目，每个项目有个项目经理，一个项目集里有一个程序经理，程序经理和众多项目经理合作，协调项目的优先级、资源等。
如果采用Scrum 开发模式，则在整个唱片线或一个系统开发中，就有多个Scrum Master，为了协调多个团队的进度、资源和任务，可以在Scrum Master上面设置一个更高层的Scrum Master，俗称Scrum Master of Scrum Master。同理，面对这种情况，我们也可以设置Test Owner of Test Owner，或称为Master Test Owner(MTO,主责任人)。这边，TO就相当于测试经理，MTO就相当于测试总监，测试经理负责项目测试计划，测试总监负责整个产品线或系统的主测试计划（Master Test Plan）,在敏捷中，TO、MTO没有权利，只有责任。道理是相通的，除了主测试计划以外，MTO要设法弥补各个团队存在的不足，而且需要指导TO的工作，帮助TO提高测试计划和管理能力。
图2 大规模软件敏捷研发团队的构成