我们第 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 公司。

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

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

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

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

-– ### 精选评论 ##### *五： > 对测试的要求越来越高了，感觉很有挑战性，加油！ ######     编辑回复： >     是啊，行业再不停地发展对人才的要求也会越来越高，和拉勾教育一起努力学习，一定会取得不错的进步~ ##### **1206： > 我们这边当前是开发负责进度，测试负责质量，如果开发这边质量过差，bug很多而导致进度延期，那是开发的责任，版本外发后有质量问题反馈，也是测试的责任。 开发担了一定程度上的质量责任，不过现在看来还是不够，意识上外面出现问题开发和测试应该都担责任 感觉也可以将需求评审，开发设计宣讲中提出的问题记录下来，提醒开发这类也是问题，是测试提前发现的bug，只是没入库而已 ##### **8567： > 提问：“测试人员可以不参与开发阶段的测试，但是需要对产品的每一迭代版本进行验收测试。”这和小瀑布的伪迭代的本质区别是什么呢“敏捷模式下，独立的测试团队可以取消，测试人员真正变成敏捷团队中的一员”非常的赞同，但是实际情况是可预见的几年内部门是不会取消的，那么必然存在对立，这种情况下，敏捷是否还能够达成，或者做到更敏捷，持续测试呢？ ######     讲师回复： >     “测试人员可以不参与开发阶段的测试，但是需要对产品的每一迭代版本进行验收测试” 中的“验收测试”，是针对每个用户故事或开发任务进行DoD验收，虽然不做单元测试/集成测试（开发测试），这个过程也可以是持续的，而不同于小瀑布。 如果项目中测试团队存在，就说明没有做到敏捷，或者说是伪敏捷。测试团队 不同于 测试部门，例如测试人员归测试部门管理，但都被打散进入项目中，而且主要有项目/产品线考核，那还可以敏捷。 要做到持续测试，开发与测试必须融合，要践行DevOps