在我们实际生活中，经常会听到健康和医疗专家灌输给我们这样一个有名的短语：预防胜于治疗。我们都知道这确实是非常有道理。预防各种疾病的产生总是比感染疾病之后再想办法治疗的要好的多。因为到了（感染疾病）那个时候，病毒有可能已经扩散到一个无法控制的程度，这时才来治疗已经晚了。

　　这个原则同样适用于软件测试。

　　比如说，如果能在项目开发初期已经发现了问题所在，那么项目可以避免重大的损失。在初阶段发现的问题越多，可做修复的越多，并且修复缺陷所需的付出越少。因此，越小越简单的模块组成越大越复杂的模块会更加的健壮。事实上，敏捷理念提出说测试应该尽早的集成同时应与开发并行。测试越早越好，越多越好。这是我们存亡的格言。

　　我曾经参加过这样的一个项目，开发都已经进行了几个月了之后，我参与进去（测试）。项目的很多核心功能都已经开发完毕，但是却没有经过任何的测试。因此，我必须通过这样或那样的方法来赶上开发的进度。

　　很自然地，团队的其他人不可能会停下来等我，因为他们的任务也有截止期限。因此，在开发团队忘记他们在几个月之前所写的代码以前，我必须加班加点的去提交我的缺陷报告给他们。在刚开始那几个星期，我的工作压力非常之高，导致我没办法集中精力在需求以及思考更多不同的测试场景。

　　除了项目团队需要忍受高强度的工作压力之外，项目本身所受到的伤害其实也非常明显。正如我之前所提到的，如果不能从根本上找出问题的所在，那么其他模块有可能受到多米诺影响，所有功能都遭到损害。在我举的这个例子当中，修复缺陷这个过程所需要的时间远远的超出了预期。实际上为了修复有些问题，导致开发人员需要追踪到他们在几个世纪以前所编写的代码。当应用这些修复的时候，会有很高的风险，因为其他地方也有可能会被这个修复所影响到。为了不把所有事情搞砸，也为了不给开发人员增加压力，此时的修复必须小心谨慎。

　　像病毒在有机体内蔓延一样，软件缺陷同样可以传染整个系统。如果有些重要的事情没有准确定位或及时处理，那么由此而产生的影响将是灾难性的。

　　正如上图所看到的一样，一栋大厦是由一块块的砖建起来的。如果在地基的某几块砖爆裂了、丢失了或有这样那样的问题，那么整栋大厦有可能崩塌。越多的楼层建在一个不牢固的地基上，崩塌的可能性越大。

　　这也同样适用于软件开发：如果在开始阶段没有开展测试工作，缺陷被忽视的可能性很大。再次重申：测试越早越好，越多越好。