在代理商验收测试进行的第三天，测试人员发现了一个严重缺陷——“流转后的文档无法正常归档”。代理商立刻向公司的客户服务部进行了投诉。在此之后的10多天里，代理商的测试人员又陆续发现了近30个缺陷。

　　公司对产品的质量十分“震怒”，详细调查后，发现了这个问题产生的过程如下：

　　这个缺陷实际发现过一次，开发人员进行修改时，发现难度较大，决定暂停修改，得到了测试人员的认可；

　　接着大家忙于新的测试和修改工作；

　　产品发布前，开发工程师进行了修改，然后直接发布，在开发环境下问题确实得到了解决；

　　最后公司对相关人员进行了连带惩罚：

　　产品部经理、项目经理、开发工程师本季度绩效考核降为最低，即下个季度每个月份都要扣除一定比例的工资；

　　测试工程师绩效考核降为最低，同样扣除了工资。

　　上面案例的执行过程中，有几处显而易见的不合理的地方：

　　缺少文档，尤其是需求文档。文档是测试的主要依据。如果交给测试组仅仅是一个软件系统，然后告诉他“你们来测试吧，发现缺陷就提交”，我相信提交缺陷后开发与测试双方几乎会陷入喋喋不休的争吵状态。

　　测试介入太晚。只在系统测试阶段才安排测试人员进行测试，实际上质量已经失控了。尤其是没有文档，测试人员无疑会把一些“缺陷”认为是合理的，而开发人员通常会自信地人为自己的开发工作是正确的。这样，一些问题是否是缺陷就会最终交给客户来完成。质量控制和测试的相关工作没有按照合理的流程进行必然会产生这种结果。要改变这种现状测试工作就应该尽早地介入整个产品的开发流程。

　　回归测试做的不合理。案例中在回归测试时，“开发工程师修改完最后的缺陷后，把所有的模块打包，发送给客户”，这里明显还缺少一次测试。所有的缺陷应该经过修改验证后才可以发布产品，最后阶段发现的缺陷也不应例外。必须经过这道工序才可以发布产品，因为修改可能会带来新的缺陷。

　　产品发布的出口不对。案例中的产品最后是由开发人员发布的，这是十分不合理的。这些产品来自于开发环境，众所周知，很多缺陷在开发环境下运行时是不出现的。产品在经过最后的回归测试并且确定可以发布后，应该把经过测试的产品而不是来自于开发环境的产品纳入配置管理基线库，最后发布的产品应该从配置管理库中提取的。

　　缺陷流程不合理。这个带来严重后果的缺陷其实就是从不规范的流程“空隙”中逃脱的，原因主要如下：

　　缺陷的用户权限控制不严。开发工程师无权决定是否延期或者暂时停止修改某一缺陷。案例中开发工程师自己决定延期修改，测试工程师也进行了认可，这是不合理的做法。

　　没有对每个缺陷进行全程跟踪。测试工程师应该跟踪每一条缺陷，并确定修改后才可以进行关闭操作，而不是发现缺陷就完成了任务。

　　缺少了缺陷审核步骤。产品发布前，项目经理应该对产品发现的缺陷进行审核，根据修改状况来决定是否可以发布。产品带着缺陷发布也是正常的行为，例如微软的大多数产品都是带着缺陷发布的。重要的是对最后未关闭的缺陷进行合理的处理。这些缺陷要由项目经理甚至是技术总监进行审核签字后确定不进行修改后，才可以转入产品发布。本案例中如果事先对缺陷做过审核并确认，就可以规避风险。

　　上面的诸多原因，必然导致了产品会遗漏很多缺陷。实际也是如此。开始发现的这个“严重缺陷”只是个开端，后面陆续发现的30多个缺陷才是上面这些原因的“所以”。如果这30多个缺陷都要进行惩罚，公司可以收入一大笔。虽然公司根本目的是想把产品质量做好，并不希望处罚大家，可是找不出提高质量的根本方法，只能出此下策以儆效尤。

　　产品发布后的责任究竟应该由谁来承担？作者认为，应该根据具体的问题来决定。首先要意识到产品带着一些缺陷是正常现象。如果纯属个人原因造成，个人是应当承担责任的，惩罚永远不是最有效的办法。实际上，本案例中的开发工程师在不到20天就提出了辞职并离开公司，给公司的产品开发带来更大的损失。提高质量必须从提高项目管理水平处入手，同时加强质量控制来避免类似问题发生。

　　4、小结

　　通过对上面三个案例进行分析，我们应该已经意识到质量、进度、成本是相辅相成、同等重要的，决不可以忽略任何一个方面。尤其是软件质量，决不要因为它是非硬性指标就敷衍了事。此外，软件测试作为质量控制的最重要手段，必须引起足够的重视。本文所讨论的案例，都是直接从实践中来的，且具有相当的代表性。那么，为什么为数不少的软件企业会陷入上述“怪圈”呢？归根结底就是短期利益心理在作怪。希望企业能够通过本文的案例剖析，意识到问题产生的原因的所在，进而提高软件质量管理水平，建立合理的质量管理体系。