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

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

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

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

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

让开发做更多的测试，没错，这就是我们常说的测试左移，但还是需要了解开发怎么做的测试，能不能达到专业的测试水平？一方面就是第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 或其他类似的角色吗？欢迎留言讨论。

---

第09讲：如何构建有强烈质量意识的学习型组织？

达成质量共识

在两个月之前，我写了一篇“软件测试灵魂三问”的文章，很受欢迎，有 8000 多的阅读量。而在此之前，还写过一篇“质量三问”的文章，更具有挑战，即通常所说的哲学三问，你是谁？从哪里来？到哪里去？那么，质量是什么？从哪里来？到哪里去？这样的基本问题，按道理每个公司都应该去回答，企业中的每个团队、团队中的每个成员都需要思考这样的问题，是否认同自己所在的公司给出的答案。如果不认同，怎么办？要不要进一步和公司管理层去沟通，在如今质量认知上达成共识。

只有达成质量共识，才能有统一的目标，最终驱动团队前进。在第 7 讲案例中，提到的 Etsy 公司，成功的三大经验之一就是拥有共同的目标，通过这个目标赋能，维护共同的质量文化，业务驱动研发，业务驱动测试。

那么，究竟什么是质量？ 质量就是客户的满意度。客户越满意，质量越高，而且还可以度量，比如通过日志分析或通过客户满意度调查获得。例如，阿里的质量文化就是：

做用户体验捍卫者，让客户百分之百放心

腾讯也有类似的文化，强调用户为本，一切以用户价值为依归，将社会责任融入产品及服务之中。所以成功的公司都重视质量，树立良好的质量文化。

营造质量文化

达成质量共识之后，接下来就是如何营造良好的质量文化，通过教育、培训等各种活动来不断提升对质量的认知和强化质量意识。下面给出优秀公司的几个案例，供你借鉴与思考。

腾讯公司其中有个团队认定：质量是团队尊严的起点，建议在有条件的情况下，每周从客服那里提取 10 条客户投诉的录音播放，听听客户肆无忌惮的谩骂和侮辱，品品内心撕心裂肺的疼痛和羞愧，然后再重新建立起踏踏实实的尊严。时时刻刻聚焦用户，为用户体验精雕细琢，所以在每一次提出新的想法或问题前，团队每个人都要反复琢磨分析，需求反复评审；从姿势上看，产品是开发的“孙子”，开发是测试的“孙子”，测试是运维的“孙子”，运维是用户的“孙子”。

劣质成本成为奖品：现在去华为公司许多展厅基本可以看到下面这张照片（如图 1 所示），以展示当年华为是如何进行质量教育的。当年，华为公司总裁任正非将从客户那里换回来的坏设备单板，以及一趟一趟来回的机票装裱在相框里，做为那一次质量大会的“奖品”，而且很长一段时间它成为了办公桌上最重要的一个摆设，时时刺激着每一位当事人。

图1 华为公司2000年质量大会现场

华为质量史上的“十一届三中全会”：2007 年 4 月，华为公司 70 多名中高级管理者召开了质量高级研讨会，以克劳士比“质量四项基本原则”（质量定义、质量系统、工作标准、质量衡量）为蓝本确立了华为的质量原则。会后，克劳士比的著作《Quality Is Free》（质量免费）在华为公司大卖，主管把它当做礼品送下属。

第 4 个例子来自我曾经工作过的思科（Cisco），每个员工身上都会带着这个卡（badge），上面印着思科文化（Cisco Culture），其中质量团队排在第一的位置，而且所有的文化都是基于帮助“客户成功（Customer Success）”。

图2  Cisco 公司文化的 badge

创建学习型团队

在质量文化形成过程中，同时我们需要把整个团队（包括开发和测试）转化为或打造成学习型团队。什么是学习型团队呢？

比较标准的回答是：通过培养弥漫于整个组织的学习气氛、充分发挥员工的创造性思维能力而建立起来的一种有机的、高度柔性的、扁平的、能持续发展的组织；整个团队成员不断突破自己的能力上限，创造真心向往的结果，培养全新、前瞻而开阔的思考方式，全力实现共同的抱负。

简单的回答是：团队成员拥有成长性思维、永不满足现状，不断反思与学习，精益求精，持续改进的团队。

对于传统的团队，强调有头脑的领导、新型战略；而敏捷团队则强调自我管理、自我组织的团队，享受充分授权、面对面沟通带来的收益，如图 3 所示。

图3 学习型敏捷团队

 

说起学习型团队，又要给你介绍一本书了《第五项修练——学习型组织的艺术与实务》（包括后续之作《第五项修炼·实践篇》《变革之舞》等），它由管理大师彼得·圣吉在 1995 年写成，重点谈到了新思考、新视野和四项核心修炼，其中四项核心修炼是：

（1）自我超越，侧重个人成长和学习的修炼。以人为起点，培养自己系统思考的能力，不断厘清愿景与现况，保持创造性张力，看清结构性冲突，诚实地面对真相，不断对准焦点，运用潜意识的力量打破契约关系、突破“自我超越”的障碍，从而实现自己的职业目标和人生的愿景。

（2）心智模式，这是决定我们对世界的理解方法和行为方式的那些根深蒂固的假设、归纳，甚至是图像、画面或形象。采用凝聚团体心智模式，并进行修炼，比如行动中的反思技能和探寻技能（如图 4 所示）、识别跳跃性推断、写下内心通常不会说的话，兼顾探询与辩护等。

图4  反思与反馈是达成团队愿景的有效实践

（3）共同愿景，是明确而可知的未来景象，不同于志向，它回答“我们想要创造什么”这样的问题。出自真心的共同愿景是学习实践的焦点和动力来源，只有唤醒了你对真正想成就的共同愿景，才会孕育无限的创造力，学会聆听，不断进步等。

（4）团体学习，是现代组织的基本学习单位。团队学习是协同校正、培养默契的过程，是开发团队能力和集体智慧的过程。通过团体学习，萃取团体智慧，既具有创新性又有协调一致性，通过对话（Dialogue，深度会谈）和商讨等不同的交流艺术实践来修炼，并善用冲突、消灭组织中的隐形墙等提升团队的学习能力。

而第五项修炼就是系统性思考，从而能看清行为背后的结构模式，关注反馈（这和敏捷“通过快速迭代及时获得客户反馈”是相通的），从而能够辨识动态系统整体运作的微妙特性。构建学习型组织是一个系统过程，如图 5 所示，除了上面说的五项修炼，还包括外围的变革管理、复杂过程管理、组织转型、文化更新、决策等活动。

图5  构建学习型组织的系统过程示意图

从上面讨论可以看出，学习型组织也强调思维能力、反思和反馈等，这些都有助于做好敏捷测试。系统性思维有利于我们进行全面地分析测试需求或测试范围，而创造性思维（如逆向思维、发散性思维）可以帮助我们挖掘更多的测试场景。也只有不断反思，才能改正错误、持续改进；不断获取用户的反馈，才能更好地理解用户的真正需求。

业务学习与缺陷根因分析

开始我通过腾讯、华为、思科等生动的案例来说明如何达成质量共识，如何帮助团队增强质量意识。即使团队质量意识很强，但也不知道如何做出高质量的产品，那质量意识也就失去了价值。

“做正确的事”比“正确做事”更有价值。如果需求定义错了，即做错了事情（do the wrong thing），那么以最正确的方式做事情（设计、编程）也没有价值。为了正确的把握客户需求，在学习型组织中，会注重业务知识的学习，包括通过扮演角色、场景模拟等手段能更好地领会真实的业务应用场景。在学习型组织中，不仅如第 3 讲所说的客户思维，想客户所想，从客户角度理解产品的需求，而且还要不断地收集用户反馈，进一步理解业务及其用户。

在工作中学习是主要的，其中一个重要环节就是缺陷根因分析。发现了缺陷，把缺陷修正了，还不够，还要做根本原因分析，找出缺陷产生的根本原因，然后采取措施消除其根本原因，以达到缺陷预防的目的，同时这种案例分析就是一次很好的学习，是质量文化建设的一部分，自然成为构建有强烈质量意识的学习型组织的主要活动之一。

除了构建有强烈质量意识的学习型组织之外，还有其他一些优秀实践。比如，建立多媒体形式的业务知识库、质量知识库，提高团队的学习兴趣，甚至举办质量知识竞赛，要多关注学习。其次，建立虚拟的专业技术社区，如人工智能社区、性能测试社区、自动化测试社区等，让具有共同爱好的员工能聚集在一起交流和讨论，开展一些沙龙、论坛或读书打卡等活动，鼓励学习型文化，促进公司范围内的沟通和交流，共同学习、共同进步。

最后，给你出一道思考题：我们这里推荐了《第五项修练——学习型组织的艺术与实务》，你是否看过此书？如果看过，请分享本讲没谈到的几个要点；如果没看过，可以推荐其他图书吗？欢迎留言讨论。

---

第10讲：如何更好地为测试而学？

上一讲介绍了如何构建学习型组织，这一讲则从团队成员的个人角度来讨论如何加强测试方面的学习。

在讲解之前，我先考你一个简单的问题，来自于《塔木德》经，问： “有两个男孩帮家里打扫烟囱。打扫完了，一个满脸乌黑地从烟囱里跑出来，另一个脸上一点煤灰都没有。那么，你认为哪一个男孩会去洗脸呢？”

估计你能很快地给出正确的答案。再来一个难一点的题目：英语字母表的第一个字母是 A，B 的前面当然是 A。那么最后一个字母是什么？估计有人会答错。

思维训练

这就是对你的一次思维训练，感觉如何？在前面第 3 讲我们曾经讲过敏捷测试思维方式（Mindset），这一讲我们仍然要先从思维开始说起，但这里侧重思维技能（Thinking Skills）的训练，人的思维能力是可以通过训练来提升的。思维训练的结果，可以让你具有更广阔的视野，对问题有更深层次的理解，找到更多或更好的解决问题的方法。

为了做好测试工作，我们需要具备哪些思维能力呢？我认为主要是：成长性思维、系统性思维（结构化思维）、创造性思维（包含发散性思维、逆向思维等）、批判性思维和用户思维。成长性思维在第 3 讲已经讲过了，批判性思维和用户思维以后会讲到，这里侧重讲解系统性思维和创造性思维。

图1 以自我为中心的测试认知

系统性思维

我们对软件测试的认识一般来自于日常工作，是以自我为中心的，所以这种认知难免是片面的、零散、混乱的，如图 1 所示。而系统性思维能帮助你打破这种对测试的认知方式，让你能够了解软件测试的概貌和整体结构，它还可以帮你整体地、多角度、多层次地分析测试对象及其测试范围、测试风险等，制定有效的测试策略，选择更合适的测试方法。

结构化思维也属于系统性思维。从系统的构成来看，一个系统一定可以分解成若干个单元，而它们也一定是结构化的、具有层次的。作为敏捷测试人员，如果你需要完成一个复杂的被测系统的测试计划或业务级别的测试任务，可以运用结构化的思维，把一个大的被测系统分解成不同模块和子系统，各个击破。例如，为每个模块设计不同类型的测试，采用不同的测试方法、选择不同的测试工具。

图2 我对测试的认知 - 软件测试全景高清图

有人说我绘制的“软件测试全景图（图 2，高清图）”是系统性思维的最佳呈现，因为它全面系统地展示了什么是软件测试，也代表了我对软件测试的看法。

创造性思维

在软件测试分析和设计中，我们需要借助发散性思维挖掘更多的测试点或应用场景，识别出更多的测试风险。在工作中你可以和同事一起采用“头脑风暴”的方式进行测试分析和设计，刺激大家打破惯有的思路，跳出原有的思维框框，畅所欲言，这对每个人的发散性思维是一个很好的激发和训练。

我们可以用发散性思维给现在比较火的视频会议移动端 App 设计临界点测试。图3 就是以思维导图的形式给出了一些测试点，你可以想想还有哪些临界点值得考虑？

图3 视频会议 App 临界测试的测试范围

我们在测试中也常用到逆向思维，借助逆向思维发现更多的异常操作、异常数据，设计出更多的负面测试用例， 大多数做测试的都具备这种测试思维，开发人员往往是正向思维去构建系统。发散思维鼓励我们往不同的方向去思考问题，逆向思维鼓励我们往反方向去思考问题，往往能找到真正的问题。

一个有效的运用逆向思维的策略是，在讨论问题的时候，注意大家都关注的点或方向，然后逆向看，朝着完全不同的方向去思考。这样的例子很多，比如操作对了会呈现这样的结果，但我们应该想到，如果用户操作错了，会怎样？这个地方让我输入数字，如果我不输入数字，又会如何？在手机 App 上开视频会议，需要用到手机自带的相机和麦克风，那么你可以在会议启动前，或者在会议中关闭相机和麦克风的使用权限，在这样的场景下测试手机 App 会表现如何。

更详细的讲解，可以到我的个人公众号“软件质量报道”里，找出我之前写的这类文章来学习。看文章还不够的话，推荐下面几本书，这样更能系统的学习和反复练习。思维能力的提升，不仅对测试的学习和工作有帮助，我相信在很多方面你都会受益。

图4 推荐的几本书

专业训练

接下来我们讨论测试方面的专业训练。我曾经给过一个针对个人的软件测试能力模型，现在又把这个模型进行了一次更新，如图 5 所示。它包括 4 个模块：测试的基本能力、业务测试能力、测试开发能力和测试技术管理能力。下面挑出对敏捷测试人员重要的三项技能讲一讲。

图5 软件测试能力模型

测试自动化

有人说，你可以不懂测试，但是不能不懂测试自动化，这话肯定不对，但多少说出了当前的行业现实：重测试开发、轻手工测试。不过在敏捷测试里，测试自动化确实很重要，是实现持续交付的基础，所以对于测试人员的自动化技能要求很高。测试自动化能力的培养主要靠自己多练习、多实践，循序渐进。

例如，可以先学会搭建和使用测试工具，学习用 Python、Java 等语言编写测试脚本，再学习测试工具和测试框架的开发和优化，以及完成自动化测试和持续集成环境的集成。如果带团队，还需要负责制定和实施整个团队的自动化测试策略。

测试建模

学会测试建模就是掌握了一种高级的测试分析 / 设计能力，学习它可以从以下两个方面入手。

基于模型的测试（Model Based Test）：是测试需求分析和测试设计的建模，把业务需求通过模型抽象为测试需求，进而转化成可执行的测试用例。MBT 也不是特别高深，像因果图、分类树、业务流程图等都可以理解为测试建模。比较专业的测试建模方法，主要包括基于事件流建模、基于有限状态机建模和形式化方法来建模。

测试自动化建模：这可以看成是上一步的延伸，先根据测试需求来完成上述测试建模，再实现自动生成测试数据、测试脚本等功能。平常所说的测试自动化并不是真正的自动化，只能算“半自动化测试”，因为测试脚本需要工程师手工编写，只有测试执行是自动的。有一些 MBT 工具，比如微软开发的 Spec Explorer，可以实现测试自动化脚本的生成和执行，相当于集成了自动化测试框架，从而实现更彻底的测试自动化。

如果更广义地看测试建模，也包括测试过程建模，如比较熟悉的 W 模型、TMap 模型等，在第 4 讲中也给出了敏捷测试过程模型，你也可以基于这个敏捷测试过程模型，构建更适合自己的，这更能加深你对敏捷测试的理解，并能更好地实施和改进敏捷测试。

探索式测试

在传统的软件测试里可以经常使用，但它符合敏捷测试价值观和敏捷测试原则，在敏捷测试中更能发挥作用，因为探索式测试更关注人，关注产品本身，有更多的沟通，更强调不断学习、持续反馈和持续优化，非常符合持续交付的需求，因此已成为敏捷测试人员必备的专业技能，我在后面还会详细讲解。

阅读博客与走出去参加会议、沙龙

在国外，很多人习惯用博客进行交流，你可以在里面得到很多信息，包括发表的文章、在线课程安排及活动通知。我有总结和分享的习惯，曾经在 2013 年 CSDN 的博客里发表了一篇文章，总结了“软件测试 Top 120 Blog”，到目前阅读量已经两万多了。

这里我重点推荐几个敏捷测试相关的博客。

• Michael Bolton 的博客：Michael 和 James Bach 共同开发了快速软件测试的测试方法，他的博客主要介绍了上下文驱动、探索式测试等内容。

• James Bach 的博客：主要也介绍了上下文驱动、探索式测试等内容。

• Lisa Crispin 的博客：第 5 讲讨论的两本敏捷测试作者之一，有关敏捷测试的内容比较多。

• Lisa 和 Janet Gregory 还有一个关于敏捷测试的共同博客，我就是在这里找到了她们对敏捷测试的定义。

• Alan Page 的博客：Alan 是《微软软件测试之道》的主要作者，和 Brent Jensen 共同提出了现代测试的七个原则。

另外一种比较重要的学习方式就是走出去参加各种相关的沙龙、会议，线下、线上的都可以，这样可以结识更多的测试同行及相关领域的专家，及时了解他们都在研究什么方向。不仅可以参加测试相关的，还可以参加讨论软件质量、敏捷开发、持续交付及 DevOps 相关的。

最后，我们来公布刚开始讨论的那两道题的答案。

第一个故事：两个男孩一起打扫同一个烟囱，不可能出现一个脸干净、另一个脸脏的情况，这个完整的故事建议你抽空找来读一下，对批判性思维会有更深的理解。

另外一个难点的题目是测试一下你的发散性思维，字母表的英文是 Alphabet，那么最后一个字母当然是 t 了。

最后，给你出一道思考题：你对自己的职业发展有清晰的目标吗？可否在留言中写 1~3 条目标？事后，可以结合自己的目标，做一个为期一年的学习计划，到时欢迎去我们的敏捷测试微信群内分享。

---

第11讲：产品、测试与开发如何协作？

在敏捷宣言核心的四句话中，第一句就是“个体与协作胜于流程和工具”，在敏捷中，强调自我管理，团队对质量负责、对测试负责，这些也离不开协作。Lisa 和 Janet 在 2017 年给出的“敏捷测试定义”中认为：敏捷测试就是从开始到交付的协作测试实践，并支持高质量产品的频繁交付……。如果高度概括的话，敏捷测试就是协作测试实践。这些都说明，协作在敏捷测试中是非常重要的。

团队协作的五大障碍

团队协作包括团队精神、沟通技巧、人际交往能力、谈判与冲突管理、信息透明和组织的敏捷性等。敏捷组织本身已经奠定了组织敏捷性，而其每日站会就是一个典型的“信息透明”例子，每个人把昨天做过的、今天将要做的和遇到了什么困难等都向团队汇报，让每个人了解其他人所做的工作及其状态，你我进行开放式交流，极大提升项目的可视性。

谈到团队协作，其实不容易，会存在各种问题，喜欢以自我为中心、个人英雄主义，而且许多研发工程师不善于表达和沟通，也缺乏良好的人际交往能力，所以在软件研发过程中，团队协作的确是一个比较大的挑战。这里，推荐一本书《团队协作的五大障碍》(Patrick Lencioni 著) ，其主题是：来了一位新的 CEO 凯瑟琳，如何逐个突破团队协作的五大障碍，将一支涣散的团队打造成团结协作的团队，从而使公司销售业绩一路攀升。

那这五大障碍是什么？

缺乏信任。没有信任，任何一个团队都没法谈协作，因为信任是团队协作的基础，它很重要，但又很难做到。信任是比较常见的问题，一般人都不愿敞开心扉、承认自己的缺点和弱项，从而导致无法建立互相信任的基础。比如，开发和测试会经常相互不信任、喜欢“怼”：为什么这个 Bug 都测不出来？你是怎么测的啊？到底会不会测啊？懂不懂代码啊？

惧怕冲突。这里的冲突是指团队内部不同观点的直接碰撞、甚至是激烈的交锋。“惧怕冲突”比上面说的“怼”还要糟糕，“怼”至少能刺激对方成长，而这种你好我好、一团和气，有了什么想法喜欢藏着掖着，有什么质量问题往往一直存在下去，得不到解决。当面怕冲突，背后还有可能会进行人身攻击，非常不利于协作。

欠缺投入。由于缺乏信任、惧怕冲突，争论就会少，互相不愿意沟通，在协作、沟通上投入自然就会少，团队内部长期存在的深层次矛盾就无法解决，甚至越来越严重，进入恶性循环。

逃避责任，上述几大障碍的存在，自然会导致你我推卸责任、缺乏团队精神，团队成员都想将责任推得一干二净；谁表现得越好，反而越容易遭到他人的心怀怨恨，这样的结果使你我甘于平庸、丧失进取心，团队更加涣散。

无视结果，逃避责任后的结果，相当于无视团队的目标和结果，都不愿意为团队目标付出，没有信任的基础，也很难齐心协力、坚持不懈地致力于实现团队的目标。

所以，从协作管理上来看，要扫清协作路上的这五项障碍，比如，搞一些野外拓展训练（图 1）、适当聚聚餐，建立起信任关系；然后主动拿出一些主题，敞开心扉地去讨论和辩论。在辩论时，再加以正确的引导和必要的提醒，提醒某些成员注意沟通方式和善于聆听、对事不对人等。久而久之，沟通协作的气氛就建立起来了。同时，和团队一起制定明确的目标，更重要的是达成共识，有良好的绩效考核机制，奖惩分明，这样就能克服五大障碍，打造成一支协作的团队（图2）。

             

图1  这类游戏或训练可以帮助团队成员建立信任关系

             

图2  克服五大障碍，打造协作的团队

下面我就结合敏捷测试的实际要求，来谈谈测试人员如何与产品、开发等不同角色进行沟通协作，会涉及质量管理、冲突管理、团队精神、沟通技巧、人际交往能力等，目的是为了持续交付高质量的产品。

团队协作高于一切

对于团队来说，团队协作高于一切，只有团队协作，才能实现团队的目标，或者说，才能顺利且相对轻松地实现团队目标，否则即使能实现，也很累、很苦。这一点在敏捷团队中，是比较容易达成共识的，因为前面说过，“个体与协作胜于流程和工具”，这体现了敏捷的价值观，而且是第一价值观。并且，团队也是全职能的特性团队，强调团队对质量负责、对测试负责。有了这个共识，从文化和认知上，协作就没有太大障碍了，对吧？

不一定，每个角色容易从自身角度看问题，也就是“屁股决定脑袋”，比如我们很容易听到：

产品人员（PO）常说：客户的想法总变，开发不好沟通…

开发常说：产品需求总变、产品太强势，只做加法不做减法…

测试常说：需求变了都不通知、开发太霸道、测试的时间总被压缩…

现实中，人们很容易忘记敏捷宣言所提倡的“协作”，欠缺团队精神，没有从全局观点看问题。所以要有良好的协作，团队的每个成员都需要全局思维方式，摈弃“屁股决定脑袋”的思维方式，需要换位思考，多站在对方的角度看问题。

而且，团队协作还依赖于之前说的信任，依赖于团队归属感、责任感等。马斯洛需求理论告诉我们，人们既有对安全感的需求，也有对归属感的需求，问题是 安全感和归属感本身就存在矛盾。安全感让我们容易在心理上封闭起来，提防他人发现自己的弱点；而归属感则需要获得团队的认可，需要我们敞开心扉，展现彼此的善意。现实中人们往往过于追求安全感，才导致团队无法建立信任。因此，良好的团队协作需要团队成员刻意的练习，不断磨合、不断改进，才能达到较高的水平。

根据微软公司的定义，仅达成共识还远远不够，团队精神有以下 6 点：

• 制定团队共同的使命和目标

• 传达“成功必须依靠团队合作”这样坚强的信念

• 营造团队中的归属感并将你我团结在一起以实现共同的目标

• 鼓励团队成员互相帮助、互相尊重、互相信任

• 使每个人都觉得自己的工作很重要，有成就感

• 与团队成员分享责任、胜利与成功、团队品牌等

达成对质量及其管理的共识

这里谈到了“制定团队共同的使命和目标”，在敏捷研发中，“使命和目标”可以理解为“尽早、持续地交付价值给客户”，这没问题，但还不够，团队需要对这个“价值”也要达成共识。越能解决客户的问题就越有价值，那么越能让客户愉悦、越能让客户满意是不是也越有价值呢？而质量就是客户的满意度。那么这里的“价值”等不等于“质量”呢？因为质量、价值都是相对于客户而存在的，即使不能说它们完全相等，但也有很强的关系，从敏捷测试的角度来看，团队必须就“质量”达成共识，认识质量的价值。

对质量达成共识还不够，更重要的是在“质量管理”上达成共识，日常研发活动中自然伴随着质量管理，如果没有达成共识，会容易产生冲突。在敏捷中，我们希望团队有这样的质量管理共识：

• 把事情一次做对是效率最高的

• 质量是构建起来的，不是测试测出来的

• 缺陷预防比发现缺陷更有价值

• 质量由客户来评判 胜于 质量由已有的标准 / 规范来评判

• ……

这样的团队不仅会重视需求评审、设计评审、代码评审，而且会更重视写好用户故事、设计好架构、遵守代码规范等，开发人员有“代码即艺匠”这种强烈的意识。这时，测试人员指出产品需求定义不清楚、代码不规范等问题，产品和开发人员就很乐意接受，不会出现之前所说的灵魂拷问，也不会再出现相互恶怼的局面。如果在质量及其管理上，团队内部没有足够的共识，关于测试的良好协作显然是不可能的。

沟通的技巧

仅仅达成共识，就没有协作上的问题了吗？显然不是，协作还受绩效考核、责任分工、沟通技巧、人际交往能力等诸多方面的影响。就像前面所说，在奖励机制上，要奖励团队而不是奖励个人，把你我的利益捆绑在一起，激发大家一起履行监督质量的责任。惩罚也类似，比如上线时出现了遗漏的缺陷，虽然要了解问题产生的根源，适当追究某些个人的责任，但整个团队也要受到惩罚。分工及其职责要明确，在第 7 讲中已经交代了专职测试人员和开发人员在敏捷开发中合理且具体的分工。

最后侧重讨论一下沟通技巧。

首先要有勇气（敏捷的价值观之一），向产品、开发不断地反馈质量问题，有了之前的共识，勇于站出来提醒质量的风险，不会太难，千万不能视而不见，更不能给高层的主管打小报告。

其次，要有情商（情商比智商更重要），要注意方式方法，比如在需求评审时，发现了需求的问题，不要说“我认为这个地方是不对的”，可以这样说“假如我们是用户，在某个场景下，如果碰到这种情况，我们大概会这样处理，而不会那么处理，对吧”；设计评审也一样，尽量不要从自己角度看问题，而要从性能、安全性、可靠性等角度出发来指出问题，或者说：根据我们上次性能测试的结果，有一个类似的问题，所以这样的设计也很有可能会有性能问题。

虽然团队对质量负责，如果团队之前对质量不够重视或对需求评审、设计评审等不重视，指望团队自然好转，其实是不可能的。作为质量的守护者，测试人员自然要承担起建立质量和测试方面协作的主导责任，在沟通协作上，不怕困难，积极主动，一次不行两次，两次不行三次……持续地影响团队，最终会帮助团队建立良好的质量文化。

在需求、设计、产品等评审（Review）会议上，我们也需要有更多的投入，事先准备更充分些，在会议上就能提出更多的问题或疑问，从而体现出自身的价值，让这些评审会成为沟通协作的主要平台。反过来，产品、开发人员看到测试人员的表现，在测试计划、自动化测试框架设计和脚本设计等评审会上也乐于提出更多的问题。这样，即使有更多的争论，都自然而然地加强了团队的沟通与协作，更快地实现团队的使命和目标。

好了，这一讲就到这里，也意味着软技能的分享暂时告一段落，下一讲将进入硬技能，我将分享《持续交付与持续集成意味着什么》。

最后，给你出一道思考题：在你与产品、开发的协作过程中，还遇到过什么问题？有什么好的办法来处理这些问题？欢迎留言讨论。

---