《硝烟中的Scrum和XP》第14章 我们怎样做测试

第14章 我们怎样做测试

• 这是最困难的部分

你大概没法取消验收测试阶段

• 理想化的Scrum世界中，每个sprint最终会产生一个可部署的系统版本

• 很恶心的bug会因此出现。如果质量对你来说还算重要，你就应该进行验收测试。此时，团队之外的专职测试人员会用测试来攻击系统，而且这些测试是Scrum团队要么考虑不到，要么没有时间完成，或是限于三件条件无法完成的。测试人员会采取与终端用户一模一样的方式来操作系统，也就是说他们必须要手工进行测试
• “验收测试阶段”：整个测试、调试、重新发布阶段，直到得到可以用来做产品发布的版本为止

把验收测试阶段缩到最短

1. 全力提高Scrum团队交付的代码质量
2. 全力提高人工测试工作的效率（即，找到最好的测试人员；给他们最好的工具；确保他们上报那些耗费时间、却能够被自动化完成的工作）

• 我们该怎么提高Scrum团队提交的代码质量呢？

1. 把测试人员放到Scrum团队中
2. 每个sprint少做点工作

把测试人员放到Scrum团队来提高质量

• 开发人员常常是很差劲的测试人员，尤其是他们测试自己代码的时候

测试人员就是“验收的家伙”

• sprint中的任何工作，如果他不说完成，那就不能算完成
• 开发人员认为“完成”的工作，却根本无法测试！原因包括代码没有提交，或者还没有部署到测试服务器上，等等。他就应该跟开发人员一起浏览一遍“完成”检查列表
• 妙处由此而生。这下团队中就有了这样一个人，可以完美地担当组织sprint演示的职责

如果没有任何事情需要测试，那测试人员该做什么

• 这个问题会常常出现
• 首先，他应该要为测试做准备。包括编写测试规范，准备测试环境等等。开发人员有开发完的功能可供测试以后，就不用再等了，测试先生可以立刻开始测试
• 如果团队在做TDD，从第一天开始，大家都会花时间来编写测试代码，此时测试人员应该跟编写测试代码的开发人员一起结对编程。如果测试人员根本不会编程，他也应该跟开发人员结对，即便他只能坐在一边看，让开发人员敲键盘。相对于好的开发人员，好的测试人员常常能想出多种不同类型的测试，所以他们可以互补
• 在sprint计划会议中，进行到拆分故事阶段，团队会把注意力放在编程性任务上，但一般在sprint中都会有很多非编程性任务需要完成。如果在sprint计划阶段花上一些时间来找出非编程性任务，测试先生就有机会来做出大量贡献，即使也不会编程，当前也没有测试工作要做
• sprint中需要完成的非编程性任务的例子

1. 搭建测试环境
2. 明确需求
3. 与运营部门讨论部署的操作细节
4. 编写部署文档（版本说明，RFC，或任何在你们组织中要写的东西）
5. 和外界的资源进行联系（例如GUI设计师）
6. 改进构建脚本
7. 将故事进一步拆分成任务
8. 标识出来自开发人员的核心问题并协助解决这些问题

在每个sprint中少做工作来提高质量

• 这会自动带来质量提升、验收测试周期缩短、影响终端用户的bug减少，并在短期内得到更高的生产力，因为团队可以始终关注于新的东西，而不是不断修复出现问题的旧功能

验收测试应该作为sprint的一部分么

• sprint是有时间盒限制的。验收测试（在我的定义中，它要包括调试和再次发布）的时间却很难固定。如果时间用完了，你还有一个严重的bug怎么办？是要带着这个严重bug交付上线，还是等到下个sprint再说？大多数情况下，这两种解决方案都是不可接受的。所以我们把人工验收测试排除在外
• 如果有多个团队开发同一个产品，那就得等所有团队的工作成果合并以后，再进行人工验收测试。如果每个团队都在sprint中进行人工验收，最后还是要有一个团队测试最终版本，而且这个版本集成了全部团队的工作

sprint周期vs.验收测试周期

• 在完美的Scrum世界中，你根本不需要验收测试阶段，因为每个Scrum团队在每个sprint结束以后，都会发布一个新的可供产品化的版本

• 不过下面这张图更符合实际情况了

• 在sprint1之后，我们得到了满是bug是1.0.0版本。在sprint2中，bug报告开始涌入，团队花了大部分的时间来进行调试，然后又被迫在sprint的中期发布了修复了bug的1.0.1版本。到了sprint2末尾，他们发布了1.1.0版本，提供了一些新特性，但bug数量有增无减，因为他们从上一个版本发布以后就一直被bug所干扰，所以能够用来保证代码质量的时间就更少。然后就一直这样循环下去……
• 在sprint2中的斜线表明有混乱的存在
• 我们目前还没有发现这个问题的解决方案。不过还是尝试过许多不同的模型
• 首先，还是全力提高Scrum团队发布的代码质量。在一个sprint中及早发现并修复bug，要比sprint结束以后再这样做的代价小得多
• 在sprint结束后还是有bug报告出来。那我们是怎么做的呢？

方式1：“在旧版本可以产品化之前，不构建新特性”

• 我们不喜欢在sprint之间加上无时限的发布阶段，主要是因为它可能会破坏sprint的节奏。我们再也无法说出“每三周启动一个新的sprint”这样的话来。另外，它也没法根除问题。即使有一个发布阶段，依然会不时出现紧急的bug报告 ，我们不得不为它们做好准备

方式2：“可以开始构建新东西，但是要给‘将旧功能产品化’分配高优先级”

• 一般我们完成一个sprint以后就会开始进行下一下。但是我们会在接下来的sprint中花一些时间解决过往sprint中留下的bug。如果修复bug占用了太多时间，从而导致接下来的sprint遭到严重破坏，我们就会分析问题产生的原因以及如何提高质量。我们会确保sprint的长度，使之足以完成对上个sprint中一定数量bug的修复
• 随着时间推移，经过几个月以后，修复上个sprint遗留bug所用的时间就会减少。而且当bug发生以后，所牵的人也更少了，所以不会总是干扰整个团队。现在这种做法已经得到了更多人的认可

糟糕的方式——“只关注构建新东西”

别把最慢的一环逼太紧

• 假设你的验收测试团队每星期最多测试三个特性（不，我们不会用“每周测试的特性”来进行度量，我只是在这个例子中用一下而已），而开发人员每星期能够开发6个特性
• 经理或者产品负责人（甚至团队）会觉得不妨安排每周开发6个特性
• 实际上，应该安排每周只完成3个特性，多余的时间用来攻克测试的瓶颈

1. 让一些开发人员去做测试人员的工作（呃，他们会因此而爱你的……）
2. 实现一些工具或脚本，用来简化测试工作
3. 增加更多的自动化测试代码
4. 延长sprint长度，把验收测试放到sprint里面来
5. 把一些sprint定义为“测试sprint”，其中整个团队都作为验收测试团队进行工作
6. 雇佣更多测试人员（即使这会意味着减少开发人员）