我问：什么测试才是良好的测试呢？

　　神说，你觉得呢？

　　我说，测试的目的是发现缺陷，所以发现的缺陷越多，那么测试越好。

　　神说，然后呢？

　　我说，我会告诉测试人员，啊哈，你们发现的缺陷越多，我就发给你们越多的奖金。

　　神说，上帝啊，又是一个糟糕管理的绝佳范例。

　　我说，恩，这样对测试人员来说，一个低劣的系统对他们的价值最高，他们会爱上那些糟糕的开发人员，引发办公室恋情。这和整个团队的目标-交付高质量的系统矛盾，并会在开发部门和测试部门之间引起矛盾和争执。还有，发现的缺陷会增加，但是获得信息的质量却降低了。

　　神说，你混淆了测试的目的，测试的目的不是发现缺陷，而是获取我们所需要的信息。作为对比，如果你所有体检的项目都正常，你会觉得体检没有价值吗？

　　神说，测试只是采样，所以良好的测试需要能够根据上下文覆盖系统中最重要的部分，而且又不能膨胀到不可管理的地步。另外，多样化样本发现的问题可能超过大样本发现的问题，同样，测试团队多样化也可能发现更多的问题。

　　我说，想起来了，我们在体检的时候往往会有不同的检查套餐，例如针对白领的，会着重检查胃和颈椎；针对40岁以上人群的，会增加癌症因子筛查。也就是测试并不是一个孤立的行为，它需要根据不同的情况采取不同的策略。而且，我们总希望体检时不用花太多的钱。

　　神说，“良好”并不是属于某个测试的属性，它只能是测试、实现、成本和应用场景四者之间关系的属性。作为比较，系统上线后用户的使用可以看做是测试的继续。

　　我说，你的意思是我们可以对系统在使用中出现的缺陷加以追踪，然后进行统计和分析，例如测试比较典型的遗漏了哪种缺陷，而哪种测试实际上是没有太多必要的，因为用户根本都没有使用该功能。这样，以后我们就可以对测试加以改进。

　　我问：那么，我们需要对所有缺陷都跟踪记录？

　　神说，你们没有对所有缺陷都跟踪记录？

　　我说，有些缺陷太小了，例如拼写错误，有些缺陷很容易就修复，所以测试人员就直接和我们说了，没有填写缺陷记录。

　　神说，你怎么看？

　　我说，我觉得还不错，没有一个开发人员愿意自己的程序里出现错误，我们往往把程序看成了自己的扩展，指出程序有错误就是在指出我有错误，所以，对于一些很小、由于疏忽引起的错误，测试人员直接和我说而不记录让我感觉好一些。

　　神说，缺陷只有在系统交付后才成为错误。

　　我说，好吧，可是报告我的程序出现缺陷会让我受到批评。

　　神说，那是另外一个关于团队管理的问题了。如果一个人花在指责其他人上面的时间越多，那么解决该问题的可能性就越低。

　　我说，可是，我们应该反对文档，文档阻碍了交流，实际上没有太大的价值。

　　神说，文档在不使用的情况下才没有价值。一些人反对的不是文档，而是反对自己写文档。信息在文档化之后才能被追踪和统计，特别是作为项目信息一部分的缺陷信息，它反映了项目的状态，一定不能够被忽略，如果为了“节省时间”和“面子”而不记录缺陷，那么导致的结果就是项目状态的丢失，会给项目后续的判断带来影响，以后会浪费更多的时间和金钱。