《敏 捷 教 练：如何打造优秀的敏捷团队》—9.4 缺陷管理

9.4  缺陷管理

团队若想在迭代结束时“完成”所有的故事，就得好好想想如何处理迭代中发现的缺陷。很明显，如果某个故事测试运行失败，肯定得先修复它，然后故事才能算作“完成”。但是，如果缺陷引出了规划会议时尚未想到的新的故事测试呢？团队是应该在当前迭代修复这个缺陷，还是推到后一个迭代再处理？

和他们一起思考对策，以此辅助他们决定下一步该做什么。如果软件已经交付实现了用户故事的主要价值，就可以推迟修复缺陷。但是，如果留着问题不解决会妨碍某个近在咫尺的发布，就得马上修复。由于这是计划之外的工作，修复缺陷可能会使团队陷入无法完成其他故事的境地。提醒团队，如果他们担心这种事情的发生，就去跟客户谈谈现在的情况。

如下实例展现了一场典型的交谈，发生在开发人员检查他们是否已“完成”的时候。

尚未全部完成

“耶！”Rebecca乐开了花。“我终于做完轮转故事了，现在就可以用。”她环顾四周，伺机炫耀一把。“Larry，你忙不？我需要你来测试一下。”

“当然。我先做完手头这个测试，然后就去帮你。”Rebecca拿了一只苹果边吃边等Larry。

“好了，你想要我做什么呢？”他一边问，一边转动椅子，以便可以看见Rebecca的屏幕。

她很骄傲地说：“我已经做完书籍轮转了，”。

“真棒。那我们一块来看看吧。”

Rebecca打开网站，打开“新书单”页面。一个立体的新书名单开始轮转。

Larry问道：“我喜欢！怎么停在自己想要的书那里呢？”Rebecca点击一本书，轮转停止。

“可以用键盘操作么？”Rebecca尝试敲击了几个键，没反应。

“看来不行，我得琢磨琢磨怎么做。”她拿起面前的一张黄色索引卡，记了下来。

第二天，Rebecca解决了问题，Larry挑选集成服务器上部署的干净版本进行测试。

“Rebecca，结果很好。不过还有些细节我想让Amanda看看。”Larry喊了一声，“嘿，Amanda，有时间吗？”

“当然，不过你得快点，我3点钟还要开个会。”她笑了笑，走到Larry的桌旁。Rebecca也加入了他们。

“我刚刚测完了Rebecca开发的轮转。但我想让你也看看我发现的一些情况。”Larry转过去对Rebecca说，“Rebecca，不如你跟Amanda演示一下它是怎么用的？”

Rebecca打开新的书籍列表页，演示给Amanda看那个轮转。“看着真不错，我喜欢！”Amanda说。

“是啊，看起来挺棒的。只是有一些小问题。”Larry伸手把鼠标拿了过来。“如果书没有图片，就会显示成这个样子。”Larry转动轮转，停在了很后面的位置。

“噢，那可不好。”Amanda皱起了眉头。

“我们该怎么处理书籍没有图片的情况呢？估算故事时我们可没想到这一点。”Rebecca说道。

“轮转里先别显示它们。然后我们再给那些书弄一张预留图片。”Amanda做出了决定。Rebecca把它作为黄色索引卡上的一个任务记了下来。

“较长的书名在IE6中无法正确显示。”Larry演示了一遍。

Larry又找到一个问题，Rebecca看起来有点小失望。“这个改起来挺棘手的，它在Firefox和Safari浏览器上都能正常显示。”

“书名得有多长才算超过了上限？”Amanda问道。

“呃，看来看去我也就只见过一两次。再看看吧。”Larry选中一个长书名，将它复制到编辑器里统计字数。“98个字符，看起来它在第95个字符的地方被截断了。”

“Rebecca，你能查一查有多少本书的书名是超过95个字的吗？”Amanda瞟了一眼手表，问道。

“我看看，”Rebecca说道，赶紧写了一条数据库查询。“四本。”

“四本？总共多少本？”

“刚过5000本。”

“还行，我能忍受。这个迭代就别急着修复了。你还是先做那个推荐引擎故事吧。”

“好。我先修复缺图片的问题，明天可以开始做推荐故事。”Rebecca眉开眼笑，如释重负。

“太棒了！好吧，我得赶紧过去开会了。”Amanda抓住放在打印机上的一份报告，补充说道，“我要是能赶回来就找你们俩一起吃饭，咱们去试试那家新开发的果汁吧。”

上述故事中，团队使用了黄色卡片来记录缺陷，放在板上很显眼，一看就知道有缺陷需要修复。你会发现，测试人员只跟客户讨论了边界用例。客户做出决定，推迟修复书名过长带来的显示问题，因为她发现这只影响到很少的几本书而已。为避免陷入缺陷追踪的灰色地带，这个故事并未阐述记录缺陷的方法。

标出失败的测试

阻止测试人员，别让他们把缺陷报告“埋葬”到缺陷追踪器里。相反，鼓励他们使用团队板来标记出失败的测试，让整个团队都能看到。这样一来就很清楚了，团队得先解决这些问题才能完成此故事。

通过邮件报告缺陷
Rachel

我刚刚合作过的一个团队，有个测试人员总是用邮件交流她所发现的问题，同时还抄送给QA部门的老大。开发人员非常希望她能先跟大伙谈过之后，再把邮件发给团队外的人，尤其是开发人员忙于编码根本没时间经常检查邮件。她的解释是她不想打扰大家，而她也让QA经理了解情况是为了证明团队需要增加一名测试人员。

很不幸，开发人员开始忽视她的存在，没有问过她就直接往现场环境上部署变更。这简直就是火上浇油！QA的老大召集整个团队，试图通过一个工作坊来处理此状况。

团队共同约定，从今往后，测试人员如果发现了故事的问题，要用彩色卡片在团队板上标记出来。开发人员会在卡片上标出已修复版本的版本号。通过这种方式，测试人员不会打扰开发人员，也不会把问题埋葬在邮件中。

安东尼·马卡诺(Antony Marcano)警告我们，缺陷追踪器会变作一个隐藏列表(参见下面的补充材料)。我们喜欢他的建议，把延迟的缺陷当作新的故事，放入用户故事backlog[1]留给后续迭代。不需要单独使用缺陷追踪工具，虽然有一个也不错，但可以以电子形式存储缺陷的细节，例如截屏。

隐藏的backlog——Antony Marcano，testingReflections

我曾是一个成立已久的团队的其中一员，该团队每一两周都能交付可工作软件。迭代中，只要觉得故事已接近完成，我们就会进行探索式测试。一旦发现缺陷，我们就会及时记入缺陷追踪系统。有时我们会直接修复缺陷，有时也会交由客户来决定。

我们使用测试驱动开发(TDD)，也即在每次修复缺陷之前，我们会先写一个自动化的故事测试来重现它。由此我想到，这些缺陷其实就是我们之前没有想到的那些故事测试。

我们必须在缺陷追踪系统中填写缺陷报告，在自动化测试中又重复一遍相同的信息，这挺浪费时间的，大家都很沮丧。缺陷追踪仅仅帮我们解决了一个问题，即追踪状态和干活的人。

我意识到，如果缺陷报告近似于故事测试，当然可以把一个或多个缺陷概括为一个新的用户故事。我们知道怎么管理用户故事！就在那一刻，我发现这个事实，我们其实有两个backlog！一个是由用户故事记载的尚未实现的行为backlog，另一个是缺陷追踪系统中记录的缺失行为的backlog！缺陷追踪系统其本质就是一个隐藏backlog。

维护这些孤立的backlog会产生副作用，我们区别对待了缺陷和故事。我们并未使用相同的方式，或是在同一时间对它们进行优先级排序。我曾见过团队专门预留出一部分时间用于修复之前迭代的缺陷，但并未和当前迭代的故事合并进行优先级排序，或者无视backlog中价值更高的故事，预留时间修复所有缺陷。按照这种方式，我们预留时间进行缺陷修复，无视其影响，有时这会导致我们选择一个比新故事价值更低的缺陷进行修复,反之亦然。

如今在新项目中，只有需要时我们才会在缺陷追踪系统中新建一个项目。我已经有很长时间没有发现这种需求了。

记住，条条大路通罗马。我们也曾见过一些团队，为了免于创建隐藏的backlog，他们就把所有的缺陷和故事统统放进缺陷追踪器(例如Trac[1])，并把它用作规划工具。此方法需要客户也得懂技术，要能投入时间学习新工具，而不是只会用电子表格之类较为熟悉的办公工具。

找到问题的根源

每次找到缺陷，都是一次流程改进的好机会。鼓励团队找出导致缺陷的原因，思考是否可以在下一迭代中避免它的发生。每找到一个缺陷，都可以讨论，也可以等到回归会议时再集中探讨。在第10章“用测试来驱动开发”中，我们会进一步谈谈开发人员如何改进代码质量并减少代码缺陷。