8.1警示性的故事

第8章 报告缺陷

“一组程序员正在向皇帝汇报。‘今年最大的成就是什么？’皇帝问。程序员们在一起商量了一下然后回答道：‘我们今年比去年多修复了50%的缺陷。’皇帝疑惑地看着他们。很显然，他不知道什么是缺陷。他与身边的大臣小声商量了一阵之后，转过身面对着这些程序员，气得满脸通红。‘质量控制得这么差，你们这是在犯罪。明年不许再有缺陷！’他命令道。可以肯定的是，到了第二年程序员们再次向皇帝汇报的时候，对于缺陷绝对只字不提。”——Geoffrey James, 《The Zen of Programming》

 

图8-1 （现实中的）昆虫的生命周期。现实中的昆虫有一个定义良好的生命周期，每个种类的昆虫又有所不同。昆虫的蜕变是软件缺陷的一个很好的隐喻：开始是对客户不满意点的可能来源的简单观察（虫卵），接着对观察到的症状、重现步骤和技术调查生成一个定义良好的报告（幼虫），然后是修复问题（蛹），最后是带有已确认问题修复的可工作构建版本（成虫）。像现实中的昆虫一样，不是所有的软件缺陷都能活到成虫阶段。当然，与现实中的昆虫不同的是，软件的缺陷能够在修复不成功时又返回到它们的幼虫状态。这就是重新激活

在价值增加的思想中，质量始终都和每个人有关。防止错误是每项活动的最重要的内容之一。那么，为什么我要为缺陷单独写一章呢——这是过时的思想吗？在大多数我所见过的组织文化中，缺陷是如此重要以至于应当迎面解决它们。即便是最著名的生命周期和开发实践，也会有缺陷发生，虽然它们的本质变化了。因此这一章是很有必要的。用于敏捷软件开发的MSF定义了这样一个原则：

质量是每个人每天的工作。质量既需要防止缺陷，又需要确认解决方案；既要应用代码分析和同行评审等实践来防止缺陷，又要最大化测试来寻找缺陷。所有角色都要承担缺陷的防止和确认的责任。

为了与MSF保持一致，我们把缺陷叫做“缺陷”而不是“defect（缺点）”。缺点通常含有过失和与规格说明书不一致的意思，这二者都会分散我们的注意力。从价值增加的观点来看，任何使感知价值（perceived value）降低的事都是缺陷，都应该考虑被优先分配并作为潜在的变更。出于同样的原因，在这里我不区分缺陷和变更请求，虽然在某些过程中，它们要受到不同的对待。我对它们全部采用相同的方法。

隐式和显式的变更请求

为了与拥抱变更这一敏捷价值保持一致，用于敏捷软件开发的MSF没有变更请求这一工作项类型。根据需求范围的不同，可以捕获变更并把其作为缺陷或者新的应用场景。

另一方面，在用于CMMI过程改进的MSF中，有一个显式的变更请求工作项类型，它可以支持CMMI的配置管理过程域。

8.1警示性的故事

让我们再来看一下我们项目中那两个测试人员凯列班和艾瑞尔的练习。在项目结束时，凯列班报告了100个缺陷；艾瑞尔报告了74个缺陷（假设缺陷的优先级和严重程度是相同的）。普洛斯彼罗是他们的经理，必须从这两个测试人员中选择一个派到关键的新项目中去。普洛斯彼罗会选择谁呢？如果仅基于这一信息，他可能会选凯列班。

普洛斯彼罗注意到：客户所收到的缺陷修复中，80%来自艾瑞尔的工作，只有20%来自凯列班的工作。因此，普洛斯彼罗选择了艾瑞尔。

这一实例的用意在于：应该提高对缺陷生命周期的重视，而不是仅重视缺陷(像叶子上的一个虫卵那样)的初始状态。在你报告缺陷和客户收到经过缺陷修复的软件的时间里，发生了很多事情。重要的是以正确的材料创建“虫卵”并让它以正确的路径成熟