6 敏捷团队究竟要不要专职的测试人员
随着facebook和google在商业上取得巨大成功，他们的开发模式引起了广泛讨论，和敏捷挂上了钩，同时引来了”敏捷团队需不需要专职的测试人员“这样有争议的问题。人的问题是最关键的问题，所以我们有必要在这里讨论一下。有必要澄清的是，这里讨论【需不需要专门做测试（测试计划、分析/设计、执行）的人】与头衔无关，现在很多公司的开发和测试都叫软件工程师，但有一部分是专门做测试工作的。还有的公司叫QA，做的事情是测试的活。很多人认为需要，也有很多人认为不需要，在敏捷和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模式还是传统产品模式
- 是否为关键业务系统，即是否是使命攸关系统（如金融、电信等核心处理系统）或性命攸关系统（如航空、航天、核工业等核心系统）
有时还需要考虑系统是否强耦合，是否是大规模的复杂系统等。
不论有没有专职测试，都不违背敏捷价值观和敏捷原则。根据国际敏捷联盟的定义，敏捷团队应该具备软件交付所需要的所有能力。而角色和责任的划分与团队输出结果----”快速交付可工作的软件“相比并不重要，开发人员可以做测试，业务分析师或者领域专家可以提出关于技术实现的想法，同样，测试人员也可以做开发和需求分析。敏捷模式下强调的是整个团队对可交付的软件质量负责，对测试负责，强调团队协作，发挥团队的做用，当团队具有很强的敏捷思维方式和相应的能力时，可以考虑逐渐减少相应的测试人员。
什么情况下可以考虑没有专职的测试人员？
- 团队质量内建的文化已经形成，敏捷测试思维/价值观构建完毕，团队成员技术能力和责任感表现优秀
- 软件运营模式是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 也不做回归测试。这个案例在下一讲中还会继续讨论，因为我们正好要讲敏捷团队有专职测试人员的情况。
