1．引言：

生产软件的企业安排很多人来测试它们的软件产品。测试的目的是发现bug（缺陷，defect）以便修正它们。正常情况是尽快处理可能的bug，从而减少修正bug的成本。因为，众所周知，bug越早被发现并修正，所消耗的资源越少。问题是在很多情况下，由于修正已发现的bug，测试过程不得不停顿下来。

那么，以目前正忙于软件产品测试的同样资源来促进组织长期的质量目标不是更好？为了做到这一点，我们应该尽快地提前发现可能的bug。像克劳士比（Philip Crosby）几年前所说的那样，我们应该努力预防bug，而不仅仅是修正它们。这是真正的质量。

2．目标：预防bug

预防的重要性

正如我们所知，bug应该尽早地在开发过程中被发现。修正处于开发阶段的产品的bug的成本远远低于修正处于QC（Quality Control，质量控制）阶段的产品的bug，而相对与修正已经发布给客户的产品的bug的成本更是可以忽略不计。原因是当你修正一个bug的时候，相当于把你之前做的事情重做一次。因此，越晚修正bug，你所重做的事情越多。如果bug修正是在产品测试之前，那么重做的工作只有代码实现。如果bug修是在测试阶段，那么重做的工作包括代码实现和测试。另一个导致成本增加的因素是依赖的组件和流程（process），随着项目的进行，产品依赖的组件和流程也会随之增加。

接下来，从另一个层面来讨论这个问题。如果bug发现和修正越早，开发成本越少，那么在第一时间避免bug引入是不是成本消耗得更少？如果bug可以被完全预防，那么在开发过程中不会出现重复工作的情况。这个被克劳士比极力推荐的观点非常有意义，而且在很多情况下已得到严密的证实。然而，并不是所有的生产软件产品的组织都试着去避免bug。它们花费了大部分的精力在产品发布给客户之前发现和修正其中的bug。在某些情况下，软件企业并不试着去达到这样的目标。在产品发布之后，企业通过迅速修正产品中的bug来处理客户的抱怨。这是因为，这样的企业始终处于“问题解决模式”，它们并不试图发现问题的根本原因，而只是把局部的大火扑灭。

这种模式并不仅仅导致重复工作直接带来成本的增加，而且会带来一个长期效应，而这将影响企业的业务。首先，发布带有bug的产品将给企业的声誉造成影响，并可能造成对潜在客户的影响??他们在是否建立合作关系上拿不定主意。另外，由于企业需要资源来不断解决现有产品中的问题，那么开发新产品的资源势必减少。

对很多人来说，零缺陷的软件产品似乎是不切实际的。我们总是听到软件开发者说：“软件永远有bug”。产品进入QC阶段时含有bug并不奇怪，因为我们“ 期望”开发人员制造bug。不幸的是，发布一个包含很多bug的产品给客户仍然不令人感到惊讶。甚至连客户本身也不再感到惊讶。

事实上，每个软件企业都可以通过一些简单的方法，在不增加任何额外资源的情况下预防bug。bug预防在于一个简单的道理：好的方法是适当借鉴我们自己的经验。