质量的外在特性是用户关心的唯一软件特性。用户只会关心软件是否容易使用，而不会关心对于程序员来说修改起来是否容易。他们关心软件是否能正确运行，而不关心里面的代码是否可读，或者是否有良好的结构。而程序员除了关心软件质量的外在特性外，还要关心它的内在特性。
大部分研究发现，检查比测试的成本更小。微软的应用程序部门发现，用代码检查这种一步到位的方法找出并修正一个错误要花费3个工作时，而通过测试这种两步完成的方法则要花费12个工作时。
令人十分惊奇的是，那些花费时间不多不少的程序员编写的程序错误最多，而那些花费时间较多或较少的程序员编写的程序所含错误则明显要少得多。
各种协同构建技术之间尽管存在着一些差异，但它们都基于一个相同的思想，那就是在工作中开发人员总会对某些错误点视而不见，而其他人不会有相同的盲点，所以开发人员让其他人来检查自己的工作是很有好处的。
各种不同的研究表明，协同开发不但在捕获错误方面比测试的效能更高，所能发现的错误类型也不同于测试。一个采用正式检查的团队报告称，复查可以快速地将所有开发者的水平提升到最优秀的开发者的高度。
由于进行完全测试实际上是不可能的，因此测试的窍门就在于选择那些最有可能找到错误的测试用例。你需要集中注意力挑选那些能告诉你不同答案的测试用例，而不选出一堆总是告诉你相同答案的测试用例。
绝大多数错误往往与少数几个具有严重缺陷的子程序有关。
调试是确定错误根本原因并纠正此错误的过程。同测试不同，后者是检测错误的过程。在一些项目中，调试可能占到整个开发周期的50%。对很多程序员来说，调试是程序设计中最为困难的部分。
同测试一样，调试本身并不是改进代码质量的方法，而是诊断代码缺陷的一种方法。软件的质量必须从开始逐步建立：开发高质量软件产品的最佳途径是精确描述需求，完善设计，并使用高质量的代码编写规范。调试只是迫不得已时采用的手段。
在运用经典的科学调试方法时，你会经历如下步骤：
- 通过可重复的试验收集数据；
- 根据相关数据的统计构造一个假说；
- 设计一个实验来证明或反证这个假说；
- 证明或反证假说；
- 根据需要重复进行上面的步骤。
如果错误只是时不时地出现，那么几乎没有可能找出它发生的原因。如果一个错误无法复现，这通常会是一个初始化错误，或者是一个同时间有关的问题，或者是悬空指针问题。
同建立能引发错误的测试用例相比，将一个错误的发生稳定下来需要更多的技巧。这包括生成能产生错误的最小化测试用例。简化测试用例的目的是使它尽可能简单，其任何方面的修改都会改变相关的错误行为。这样一来，你就可以在可控的条件，改变测试用例并仔细观察系统的变化，你就可能确定问题产生的根源。
