高效的敏捷测试第三课测试人员的选择

第06讲：敏捷团队究竟要不要专职的测试人员？

问题的提出及各方理由

随着 Fackbook 和 Google 在商业上取得的巨大成功，他们的开发模式引起了广泛的讨论，并且和敏捷挂上了钩，同时引来了“敏捷团队需不需要专职的测试人员？”这样有争议的问题。人的问题是最关键的问题，所以我们有必要在这里讨论一下。

首先要澄清的是，这里要讨论「需不需要专门做测试（测试计划、分析 / 设计、执行）的人？」，和头衔无关。因为我知道现在很多公司开发和测试都叫“软件工程师”，但有一部分就是专职做测试工作的，还有一些公司叫 QA（Quality Assurance），但做的是测试的活儿。

很多人认为需要，也有很多人认为不需要。在敏捷和 DevOps 实践中，也都能找出支持这些不同观点的成功案例，看起来似乎要形成两大阵营。

Etsy 公司在 2009 年开始引入 DevOps，建立了持续交付的全自动化部署管道，这家公司既有专职的 QA 人员又有专门的 QA 团队，他们做具体的测试工作。
微软和 Facebook 只在有些业务线保留了少量的专职测试人员，多数业务线则根本没有，测试团队更不存在。Google 则把测试团队改造为 Engineering Productivity（工程效能）团队，不为产品做测试，而是为开发人员提供测试工具和技术。

那么，软件测试行业一些大师级人物的观点如何呢？

Alan Page 和 Brent Jensen 提出了现代测试七大原则（Modern Testing Principle）。其中第七条：把测试的方法和能力扩展到整个团队，并认同团队会逐渐减少或取消专职的测试专家存在。他们认为测试人员的责任是指导团队建立更成熟的质量文化，专职的测试人员将会减少甚至取消。

而 Lisa Crispin，也就是《敏捷测试》这本书的作者之一，虽然也认同敏捷团队中专职的测试人员可以减少（她给出的例子显示，开发和专职测试的比例是 10:1），但是至少要保留一位测试专家做一些专业性强的测试，因为开发人员思考问题的角度和测试不同。而国内有很多关于这个问题的讨论文章，大多数会根据自己的切身体会表示赞同或反对。

对于“不需要专职的测试人员”这个观点，理由大概有以下几点：

质量不等于测试，质量是内建的，不是测出来的，开发应该对自己的代码质量负责。
我们不需要不懂软件开发的手工测试，因为不懂开发就做不好测试。
测试和开发分开会造成工作效能的低下，开发人员自行做相应的测试会提高效率。
很多伟大的产品都是出自没有或很少测试人员的团队。
自动化程度低的活就是体力劳动，开发很快就能掌握测试用例设计的技能。

而反方观点的理由大致如下：

需要测试领域专家，一个人不可能什么都会。
开发做测试有思维障碍和心理障碍，做不好测试。
开发人员太“贵”，让开发做测试的活儿，公司会增加比较大的成本。
存在即合理，护士的活儿医生肯定可以干吧？为啥医院还要那么多护士？
企业级软件一般都很庞大、复杂，功能、业务逻辑太多，而每个开发做的东西都比较小、比较窄，缺乏业务视野的广度和深度。

到底要不要专职的测试人员

我的观点是：要基于上下文来决定要不要专职的测试人员，需要根据具体情况来分析。

“敏捷团队究竟要不要专职的测试人员？”答案不只是：“要”或“不要”，否则会落入问题的陷阱。我经常会问学生，“结构化测试方法中，判定覆盖强呢？还是条件覆盖强呢？”，许多学生会脱口而出“条件覆盖强”，也有回答“判定覆盖强”。这样问其实很容易让人上当，或者说，不应该这样问。

要不要专职的测试人员？不能简单说，手机 App 之类的应用都不需要，电信、银行、航天 / 航空、医疗等系统则一定需要；也不能简单说，团队给力、人员素质好，而软件产品本身质量要求又不高，就不需要什么专职的测试人员。

首先要看开发愿不愿意做测试、能不能做测试？不愿做、不能做，那自然需要专职的测试人员。强迫开发做测试是不行的，这样做效果也不好，人们常说：上有政策下有对策。过分强迫的话，开发会走人的。

其次，要看系统是不是关键系统？有些系统是性命攸关的，不能有半点闪失，关键业务系统对质量风险的容忍度近乎等于零，即使开发素质高、责任心强、能做测试，一般还是需要独立专职的测试工程师，以增加一道防线。

最后，还要看这个系统是否要部署到客户那里？如果是，则版本更新很困难，出了问题也无法回滚，无法支持灰度发布，这时对质量会苛刻很多，类似上面情形，一般也需要专职的测试人员。所以，至于要不要专职的测试人员，则需要综合考虑下列主要因素：

团队情况：组织文化、人员素质和技能等；
产品运营模式，是 2B 还是 2C，是 SaaS 模式还是传统产品模式；
是否为关键业务系统，即是否是使命攸关系统（如金融、电信等核心处理系统）或性命攸关系统（如航空、航天、核工业等核心系统）。

有时还需要考虑系统是否强耦合、是否是大规模的复杂系统等。

其实不论有没有专职测试，都不违背敏捷价值观和敏捷原则。根据国际敏捷联盟（Agile Alliance）的定义，敏捷团队应该具备软件交付所需要的所有能力，而角色和责任的划分与团队输出结果——“快速交付可工作的软件”相比并不重要，开发人员可以做测试，业务分析师或领域专家可以提出关于技术实现的想法。同样，测试人员也可以做开发或需求分析。

敏捷模式下强调的是整个团队对可交付软件的质量负责、对测试负责，强调团队协作，发挥团队的作用。当团队越来越具有很强的敏捷思维方式和相应的能力时，可以考虑逐渐减少专业测试人员。

什么情况下可以考虑没有专职的测试人员呢？

团队质量内建的文化已经形成，敏捷测试思维 / 价值观构建完毕，团队成员技术能力和责任感表现优秀；
软件运营模式是 SaaS 模式，并拥有灰度发布机制，能做到快速部署、快速回滚；
不属于关键的业务系统。

如果没有专职的测试人员应该如何做

接下来我们先讨论没有专职的测试人员应该如何做，已经购买专栏的你应该是专职的测试工程师了，对于我们讨论的这个话题，不知道作何感想，欢迎留言讨论。

首先，想请你回顾一下第 3 讲中的“成长性思维”，你的能力是可以通过努力培养的，而敏捷团队对成员个人的能力要求更高。这对个人发展是好事。

我想到一个比喻：一个团队里集合了一群内外兼修的武林高手，团队需要十八般武器都有人会，而且每个人至少要会几种，这难不倒这群高手，有人原来会使剑，但通过训练，他也能用刀，甚至是棍。虽然他最擅长的还是使剑，但需要用刀的时候，对付一般人也绰绰有余，没有刀剑怎么办？在路边随手找一个棍，也能参与战斗。之后，他发现自己的剑术更加精进，已经可以做到一剑封喉的地步。

这就像测试人员掌握了编程能力，在测试方面可以更加自如地选择不同测试技术和测试工具，而开发人员通过参与测试，在代码开发阶段就会想到如何避免缺陷的产生。所以，没有技术上的广度，也就达不到技术上的深度。

相比传统测试，敏捷模式对整个团队测试能力的要求也会更高，让开发做测试，或让整个团队做测试是可以，但不能不管做的如何。如果开发做测试效率低、质量没有保证，那这种改变就不是进步，而是倒退。在没有专职测试的情况下，我们需要关注的是敏捷团队的整体测试能力。测试和开发的融合意味着测试的能力将成为整个团队的内在能力，敏捷测试思维和文化将成为整个团队的共同文化。

我在《全程软件测试》（第3版）第 4 章中，曾经讨论过如何建立整个研发团队的测试能力，这在敏捷团队里仍然有效。现在简单回顾一下 Google 所描述的团队“测试认证”模型，如表 1 所示，这个模型带有 Google 的特色，比如将测试分为三级：小型测试（类似单元测试）、中型测试和大型测试。不过，研发团队仍然可以按照这种测试能力模型的思路去规划如何提高。

表1 Google 测试能力认证的 5 种级别

这个模型侧重要求了对测试的认知、冒烟测试、集成测试、单元测试等，但对 TDD / ATDD 没有要求，对团队测试要求也不算很高，到了级别 5，单元测试覆盖率要求也只是“不低于 40%”，整体测试覆盖率不低于 60%。而且这种覆盖率如何度量？是指代码行覆盖率吗？其次，静态测试拖到级别 5 才做要求，这也是这个模型的问题之一。

需要注意的是，上面介绍的测试能力认证模型是 Google 基于 2013 年以前的测试实践总结的，如今 Google 已经成功引入了 DevOps，情况应该和 8 年前的不一样了。

单元测试和静态测试

我们在后面的内容里会讲 TDD / ATDD，这里先讲一下单元测试和静态测试，这两个都属于软件测试最基本的实践。单元测试是指对软件基本组成单元进行的测试，而且和编程同步进行，可以尽早发现程序问题；而静态测试的对象不仅是代码，还包括需求定义和设计文档等。两者都可以有效地帮助团队尽早发现软件缺陷，但是目前根据调查结果可知，二者在很多研发团队中推进的效果仍然不太理想。

ThoughWorks 公司官方公众号有一些文章介绍了他们关于单元测试和静态测试的实践：“在 ThoughtWorks，先写单元测试是程序员的基本素养，代码走查形式多样，但成熟团队一般都从单元测试开始。敏捷开发对回归测试考虑不多，质量内建意味着不希望最后靠测试把质量关。”这说明单元测试和静态测试做好了，系统测试和回归测试就可以少做、甚至不做。

另外，前面说过的 Etsy 公司每次在部署前都需要自动运行 30 个测试集（单元测试、集成测试、功能测试、冒烟测试……），而所有这些测试在 5 分钟内完成，以确保开发人员得到快速反馈。每天在 CI 环境里要运行超过 14000 个测试集，而且他们的 QA 也不做回归测试。

这个案例在下一讲中还会继续讨论，因为我们正好要讲敏捷团队有专职测试人员的情况。

最后，给你出一道思考题：你认为敏捷团队需不需要专职的测试人员呢？你的理由是什么？欢迎留言讨论。

第07讲：如果有专职的敏捷测试人员，他们的职责是什么？

我们第 6 讲讨论的是没有专职测试人员的情况，这一讲主要讨论有专职测试人员的情况。相信购买这个专栏的同学，大多数是专职测试人员，所以大家对这个话题会更感兴趣，对吧？

Etsy 公司的优秀实践：测试人员能做、应该做的事

关于敏捷测试人员的职责，让我们先来看一下来自 Etsy 公司 QA 团队在这方面的优秀实践。Etsy 公司创建于 2005 年，是美国的一家电商平台，以手工艺品买卖为主要特色，在初创期经历了 IT 架构和组织架构的摸索，直到 2008 年，新来的 CTO 开始引入 DevOps 和社区文化。经过几年的打磨，Etsy 在 2014 年英国的 QCon（全球软件开发）大会上曾经介绍他们是如何做到一天完成 50 次线上部署的（这在当时已经很了不起了），可以说一战成名。

那么他们是怎么做到的呢？

首先，公司建立了优秀的工程师文化：他们的口号是“代码即艺匠（Code as Craft）”，认为工程师是一个有创造力的群体，互相鼓励交流、协作，鼓励学习。公司定期举行技术沙龙，邀请各行业的专家进行交流分享。

其次，公司建立了优秀的质量内建文化：开发阶段的测试由开发负责。通过一键式部署管道，开发人员可以直接部署代码到生产环境上，但在部署前需要保证自己的代码是稳定的。在公司的 CI 环境里集成了超过 30 个自动化测试集。另外公司还建立了 KPI 面板量化跟踪自动化测试的代码覆盖率。

和 Facebook、Google 这些公司的实践不同的是，Etsy 有独立的 QA 团队，为所有项目提供了服务。到这里我想问问你平时都做什么具体测试呢？开发阶段的测试、回归测试、为得到测试通过率指标进行的测试、维护测试用例集，这些应该都是你的日常工作吧？但 Etsy 的 QA 团队这些都不做！

下面才是这个团队要做的事情：

针对新功能和新产品进行探索式测试、集成测试及跨平台的兼容性测试；
针对移动端的发布进行验证测试；
验证用户可感知的改变。

QA 团队还建立了团队的价值观：价值驱动、目标赋能和社区文化。

对此我的解读是这样的：

价值驱动，就是做 QA 该做的事，不为测试而测试，不会为了出统计数据而做测试；
目标赋能，全公司范围内以业务为共同目标，维护共同的质量文化，业务驱动测试；
社区文化，鼓励学习型文化，促进公司范围内的沟通和交流，共同学习、共同进步。

可以说 Etsy 公司从企业文化、价值观，再到技术、工作流程、基础设施都建立了一整套行之有效的敏捷及敏捷测试实践方法，确实值得学习。

敏捷测试人员的责任和具体任务

对照 Etsy 公司的 QA 团队，我们来总结一下，测试人员在敏捷团队中需要承担的责任和具体任务主要有以下 4 点。

（1）帮助敏捷团队提升质量文化，持续关注质量和用户需求，持续向相关利益者提供质量反馈

用户需求是软件测试非常重要的上下文之一，测试人员要帮助团队开发出客户真正需要的产品，避免陷入过多的、从技术方面思考问题的误区。不知是否还记得微软曾经在 Windows 8 上面拿掉了左下角的开始按钮和开始菜单，很多用户因此根本找不到关机和重启电脑的地方，在用户的强烈抗议下，微软最终还是彻底召回了大家平时习惯的开始菜单。这就是从技术角度而非用户角度开发产品的一个失败案例。

另外，对产品的质量要求也是一个重要的测试上下文，不仅要清楚每次交付的质量要求是什么，而且还要清楚每次迭代相比上一次有什么变化。

在具体的测试任务方面，测试人员更侧重从用户角度对产品进行质量评估，采用探索式测试方式执行功能交互测试和贯穿业务流程的 E2E 测试，并开展易用性、兼容性和可靠性、性能和安全性等方面的专项测试。

测试人员可以不参与开发阶段的测试，但是需要对产品的每一迭代版本进行验收测试。例如，Zoom 公司的开发完成新功能测试，而回归测试则由专职测试人员来做，相当于代码冻结后进行最后的回归测试——验收测试。

这项责任对应的具体任务包括：

获取和明确用户的质量期望
建立合适的系统测试、验收测试的质量标准
（和 PO）完成每个迭代的验收测试
保持质量度量结果的可视性
发现值得关注的测试切入点，持续提供质量反馈
在线日志分析、在线测试
拜访客户、用户调查等活动

（2）制定测试计划，指导团队使用合适的测试技术和方法，不断收集反馈，改进、推广测试技术和方法，积累软件测试实践

敏捷测试人员（第 8 讲将会介绍 Test Owner 角色）负责为团队制定测试计划。敏捷测试中测试计划可以短，但不能没有，比如只有一页纸，其形式可以灵活，比如用思维导图等。我在模块 5 中会详细讲。

测试人员需要负责向团队传授测试技术和经验，以帮助整个团队持续提高测试能力，比如指导开发在单元测试和系统测试中使用合适的测试技术和方法。需求、设计、代码评审需要全体成员参与，并且收集反馈，持续改进。

这项责任对应的具体任务包括：

制定测试计划模板、风险列表（Checklist）和常见的测试策略
探索新的测试方法，引入新的测试技术
开发更有效的测试工具，持续改进自动化测试（TA）
通过缺陷根因（Root Cause）分析获得避免缺陷的信息，设立规则和实践避免缺陷引入

（3）帮助团队构建自动化测试基础设施，提供必要的测试工具

这项工作你应该比较熟悉了，很多公司热衷招聘测试开发岗位，主要承担的就是这项工作。敏捷测试人员不仅为团队构建了自动化测试环境，还要考虑自动化测试框架和持续集成（CI）环境以及 DevOps 工具链的集成。

这项责任对应的具体任务包括：

推进单元测试、开发测试，尽量将测试推动到上游
建立 CI 框架以及基于 CI 的质量控制和发布规则
创建更高效的工具，持续改进自动化测试（TA）

（4）可测试性把关，包括需求、设计和代码的可测试性检查

可测试性的检查也是敏捷测试人员的一项重要责任，而且要从需求、设计开始抓起。产品需求文档过于简单，没有明确的验收标准、软件设计没有考虑给自动化测试提供接口、代码的结构复杂以至于发现缺陷后很难快速定位问题所在等，这些都会影响软件产品的可测试性。

敏捷模式有利于可测试性的提高，因为开发要对自己的代码进行测试，在代码编写时，需考虑可测试性。如果先实现单元测试代码，再开始编写代码，就更进一步，也就是实现 UTDD（单元测试驱动开发），但前提是需求的验收标准是完备和明确的。敏捷开发模式对文档不重视，需求文档和设计文档潜在的问题就比较多，测试人员需要在测试计划中考虑静态测试、组织并参加相应的评审，和团队成员一起明确用户故事的验收标准，提出设计和代码方面的可测性需求。

这项责任对应的具体任务包括：

建立合适的系统测试、验收测试质量标准；
定义需求 / 设计评审的检查表（Checklist）；
持续推动可测试性的提高。

表2 敏捷测试人员责任和具体任务（有的任务放在两个责任范围内都合适）

测试人员和开发的分工

另外，我们再总结一下敏捷测试人员和开发人员对测试任务的具体分工（第 8 讲也有一些补充），可以看一下表3，虽然角色及其责任不一样，但能更好地帮助你理解这张表。

表3 敏捷测试人员和开发人员的分工

测试敏捷化对测试组织 / 团队意味着什么

讲完测试人员的职责后，我们再来讲一下测试敏捷化对测试组织意味着什么。敏捷模式下，独立的测试团队可以取消，测试人员真正变成敏捷团队中的一员，这样更有利于开发和测试的融合。

但是，也要根据具体情况，如果某些专项测试对于业务系统来说是非常关键的质量指标，则可以考虑成立专门的性能性测试团队。例如，大型复杂的软件系统，对性能和安全的质量要求很高，性能测试和安全测试涉及的技术层面又都很广很深，需要单独的测试计划、测试技术和方法，由专门的团队来负责也是合理的。

你可能会担心：取消测试组织会造成测试人员的孤立和公司对质量的忽视。对此，企业可以建立测试社区（Test Community）这种虚拟的组织形式来代替测试团队，通过定期举办活动给所有员工提供一个交流质量文化和测试技术的平台，这样更能意识到质量是我们大家的事。不少公司都有类似的实践，比如前面讲的 Etsy 公司。

敏捷测试人员的成长 / 职业发展

最后简单讲一下敏捷测试人员的成长和职业发展。听了前面的内容，你应该已经理解了，敏捷模式下测试人员要承担的责任和任务有很多，但是干不好也容易被边缘化，因为很多任务不是那么具体和可量化，比如指导团队成员做测试，推广质量文化，不仅需要技术能力，还需要很多软技能，比如沟通和领导力。这必然会给测试人员带来巨大的挑战，但对于具有成长性思维的人来说，这又是非常好的机遇，促使你我通过多种方式快速成长，让自己在职场上更有竞争力。

学习的方式有很多：比如参加公司组织的技术沙龙、测试社区；通过论坛、活动建立与公司外部测试同行的联系；或者通过书籍，线上 / 线下课程的学习充实自己。这个我会在接下来的内容中很快会讲到。

最后，给你出一道思考题：做为敏捷团队中的测试人员，你应该如何在团队中推广质量文化？你期望团队建立什么样的质量文化呢？欢迎留言讨论。