第08讲：借助TetOwner角色，完成团队转型？

三年前的一天，我碰到了一个之前在思科的老同事，问了下他现在软件开发采用的是什么模式？

他回答："已全面实施敏捷开发模式了，有些团队都没有测试人员，测试都是开发人员自己做。"

我接着问，那怎么知道开发人员测试做得如何？效果怎样？

他回答："这个不知道，我们相信他们，他们也承诺对自己的代码质量负责任。"

让开发做更多的测试，没错，这就是我们常说的测试左移，但还是需要了解开发怎么做的测试，能不能达到专业的测试水平？一方面就是第6讲所说的，像 Google 公司那样对整个研发团队的测试能力进行认证。但是，如果认证的结果显示整个研发团队的测试能力比较低、研发达不到要求，怎么办？

这就是本讲所要讨论的主题，设置一个"Test Owner（TO）------测试责任人"角色来帮助团队提高测试能力，并完成过渡时期测试质量的控制和管理工作，包括承担起测试计划制定、测试用例的评审等责任。

冰冻三尺并非一日之寒

为什么要设置这样一个角色呢？除了上面的原因之外，我们还需要一个相对比较长的时期，以完成从传统测试向敏捷测试的平滑过渡。从传统的研发团队转型成敏捷团队，有时需要很长的时间，而且企业领导必须有决心去支持团队转型，也需要请教练来辅导团队如何具体实施新的开发模式。

差不多是 20 年前，我在 WebEx 公司参加软件产品研发的时候，那时产品经理都不属于研发团队，而是属于产品市场（Product Marketing）部门，这个部门和研发部门不一样， 更像财务、人事部门那样，直接隶属公司管理。而研发部门（包括开发、测试、项目经理等）则根据具体的业务领域分为独立的 BU（Business Unit）。这个时期研发和产品之间的那堵墙比较厚，如图 1 所示的最左边那种组织结构，产品经理把需求从墙那边扔到研发这边，研发部门接到需求，按需求进行软件设计、编码、测试。

10 年前，情况有所好转，开始往敏捷开发模式转型，比如以 Scrum 为例，设立 Product Owner（产品责任人）角色，产品设计和研发开始在一个团队，迭代周期也从之前的半年、一年缩短到一个月、一周。

最近几年，开始慢慢减少测试人员，有些团队干脆没有测试人员（这在第 6 讲已讨论过），让开发做测试，整个团队对测试、对质量负责，这个出发点是对的，也特别符合敏捷测试的思维方式。但一口吃不成胖子，不能急于求成，就像上面把"产品定义和设计"移到团队研发内部，需要设置 PO 角色。所以，当我们想彻底实现从传统测试向敏捷测试转型的过程中，也需要设置 TO 角色，如图 1 所示的下部中间结构。

概括起来，从传统开发模式向敏捷模式转型，分为两种情况，一种是将测试人员和开发人员等整合成一个全职能的特性团队，保留专职的测试人员（这在第 7 讲已讨论过），里面设置 TO 角色，而不应该设置测试经理角色（敏捷组织是自我管理的组织），会议召集或清理障碍等管理性工作，可以由 Scrum Master 来做。另一种情况是经过一个过渡阶段，再彻底实现开发与测试的融合，没有专职的测试人员，都称为软件工程师，如图 1 所示。

图1 研发组织从传统向敏捷演化（以 Scrum 为例）

多数团队不是 Google

咱们都听过这个民间谚语：一个和尚挑水喝、两个和尚抬水喝、三个和尚没水喝。当我们推行"质量由团队负责 "这样的理念时，从我国国情来看，多数团队的软件产品质量可能就没有人负责，虽然极其优秀的团队没有问题。当国内某个团队直接照搬 Google 公司的流程和实践时，有识人士就曾发文特别提醒：你公司不是 Google，你公司还不是 Google，你公司本来就不是 Google。所以对于大多数团队来说，测试还是需要责任人、需要 Owner，比较切实可行的实践是需要设置 TO 这个角色，这个角色对测试计划、测试过程和测试结果负责，虽然不对质量负责。

即使在多数情况下，也还认定"质量是构建出来的"。如果需要有人对质量负责，也可以设置 Quality Owner 这样的角色，负责促进优秀质量文化的形成、流程内审和改进、推行全过程的质量管理等。的确有些优秀的公司（如华为公司）还保留 QA（Quality Aassurance，质量保证）部门和 QA 角色。

其实，多数公司没有 QA 部门或 QA 角色，这时测试人员就或多或少要承担 QA 的部分责任，这也就是为什么许多美国公司的测试工程师被称为 QA 工程师，我在 WebEx、Cisco 时，头衔是 QA 经理、QA 高级总监等。

也算歪打正着，这样的头衔在今天来看，也是更好，因为敏捷测试提倡"预防缺陷 胜于 发现缺陷"，QA 主要责任就是通过定义好的流程、好的规范等来预防缺陷，而测试的主要责任则是发现缺陷。只是平时我们不会注重区分 QA 和测试，所以还可以说，"敏捷测试提倡：预防缺陷胜于发现缺陷"，本来我们应该说"敏捷质量管理提倡：预防缺陷胜于发现缺陷"。

TO****角色的责任和具体实践

Test Owner（TO）是以敏捷中最流行的 Scrum 方式来定义这个角色的名字，但这个角色也可以称为"测试教练（Testing Coach，TC）"、"测试顾问（Testing Consultant，TC）"或 QA，叫什么不重要，重要的是这个角色要承担哪些责任。

根据前面的讨论，我们基本清楚了这个角色的责任。

• 制定软件产品研发的迭代测试计划 。虽然是一个简单的计划，也是一个动态的过程，但计划依旧很有价值，同时指导这个迭代的测试过程，所以需要有一个人来负责计划起草、召集评审会议等，还包括测试范围分析、列出测试项、定义优先级、识别测试风险、制定测试策略、估算工作量等工作。

• 协调测试计划的执行 ，包括收集团队的反馈，洞察新的测试风险，对计划进行优化或调整，协调测试任务或测试资源等。

• 促进提高软件的可测试性，参与前期需求分析和定义验收标准，更好地保证需求、设计、代码等的可测试性，可能的话，领导团队还可制定测试性规范或实施指南。

• 指导团队成员开展测试工作。指导工作不局限于用户故事的验证、系统级别的测试，也包括单元测试、集成测试；不局限于动态测试，还包括需求评审、设计评审和代码评审等。团队成员若在测试工作中有疑问、有困难，则可以向这个角色咨询，以得到他 / 她的帮助。

• 承担部分 QA 责任。例如，领导团队制定评审流程和规范，帮助开发人员消除不规范行为，不断寻求机会以提高需求、设计、代码的质量和可复用性，积极影响开发的质量意识，和团队一起做好缺陷跟踪、缺陷分析和缺陷预防等工作，在整个开发周期中进行质量跟踪、持续改进质量。

• 其他责任 ，例如，指导团队进行测试基础设施、自动化测试框架等工作，为团队提供相应的内部测试培训帮助团队提高整体测试技术和知识等。

既然是一个角色，根据团队大小、开发人员的测试能力和其他实际情况，TO 可以由一个人担任，也可以由多个人担任，或者 2 ~ 3 个团队共同拥有一个 TO。TO 角色，一般由公司内部测试专家、原来担任过测试经理的人员来担任比较合适，他们熟悉测试流程、测试方法，之前也负责过测试项目或项目中测试的部分，制定过测试计划，管理过测试过程，也管理过团队，有经验和能力履行上述 TO 责任。如果没有测试专家、测试经理，也可以由测试架构师、或资深测试工程师担任；如果团队比较大，还可以由原来的测试经理和测试架构师联合担任。

Master Test Owner

当一个产品线需要多个同时并行的组件开发项目来完成时，或者说开发一个系统需要多个子系统的开发并行进行，这时就是我们通常所说的大规模系统开发，不是由一个敏捷团队就能完成的，而是由多个敏捷团队协作完成。在项目管理中，项目集包含多个项目，每个项目有一个项目经理，而一个项目集有一个程序经理（Program Manager），程序经理和众多项目经理合作，协调项目的优先级、资源、进度等。

如果采用 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 没有权利，只有责任。

图2 大规模软件敏捷研发团队的构成

道理是相通的，除了主测试计划以外，MTO 要设法弥补各个团队之间存在的 Gap，而且需要指导 TO 的工作，帮助 TO 提高测试计划和管理能力。

最后，给你出一道思考题：会在你的敏捷团队中设置 TO 这样的角色吗？如果不会，原因是什么？或者会设置 QA Owner 或其他类似的角色吗？欢迎留言讨论。