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

神说，又是一个糟糕管理的范例。

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

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

我说，恩，我会很高兴。

神说，测试只是采样，所以良好的测试需要能够根据上下文覆盖系统中重要的部分，而且又不能膨胀到不可管理的地步。

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

神说，“良好”并不是属于某个测试的属性，它只能是测试、实现、成本和应用场景四者之间关系的属性。

我说，无法衡量测试？

神说，作为比较，系统上线后用户的使用也可以看做是测试的继续。

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

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

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

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

神说，你怎么看？

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

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

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

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

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

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

我说，我想起来了，每次去取体检结果时，我都会看到本次体检指标与历次的对比，这次的结果提醒我胆固醇又提高了，颈椎则好了很多，所以要少吃肥肉多锻炼，同时晓庆教我的颈椎病锻炼要继续坚持。

我问：收集信息似乎只是第一步，信息的处理过程又是怎样的呢？

神说，你们是怎么做的呢？

我说，首先，测试人员会选择样本对系统进行测试。比如发现系统不能上传图片了，测试人员会报告一个缺陷，记录下详细的信息。

神说，这是第一步，摄取信息，此时，信息在被人确定含义之前是没有意义的。

我说，接着，我们会看到这个缺陷报告，并和测试人员进行交流。测试人员表示了担忧，因为上传图片对客户来说是一个很重要的功能，现在连它都不能正常工作是否意味着系统的其他部分也存在很多问题。

神说，测试人员在给信息赋予含义。

我说，我们和测试人员一起重现了这个缺陷，系统报出的问题是权限认证失败，我们认为这是一个权限方面的问题，上传图片的其余功能应该不受影响，也许是有人改动过当前测试用户的权限，也有可能是上一次提交破坏了什么东西，总之影响不会很大，因为这块有很多的单元功能测试，如果是提交破坏，也应该是页面上的代码，这段代码不多，错误能够很快定位和修复。

神说，你们在给信息赋予含义，不同的人会给信息确定不同的含义。

我说，接下来，我们会讨论这个缺陷的优先级。测试人员认为这个缺陷很重要，应该立刻修复；我们认为这个缺陷虽然重要，但是非常容易修复，并且此时有另外一个非常重要的缺陷需要修复；项目经理询问了我们各自对这个缺陷的理解，说，我们现在有一个特别重要的关于图片搜索的缺陷需要修复，我认为这个缺陷重要，因为后天需要给客户的老板进行演示，上传图片的功能也很重要，但是不在演示的范围之内，但是既然很容易定位，我们也可以迅速的查明引起问题的原因，但是不修复。

神说，现在在确定信息的重要性，并做出反应。不同的人会给信息确定不同的重要性。

我说，那么完整的过程应该是：摄取信息->确定含义->确定重要性->做出反应。

神说，是的。

我说，等等，我看到问题了。因为不同的人会确定不同的含义，不同的人会确定不同的重要性，所以对做出决定的人来说，他一定要有自己的理解和权衡，并根据自己的重要性和其他信息终做出决定。但是现实情况却并非如此，很多信息在提供给管理者之前已经被信息提供者赋予了他所定义的含义和重要性，而管理者由于不能获取其他信息或干脆没有思考，所以直接根据信息提供者所定义的含义和重要性做出决定了。

神说，你想到了什么？

我说，忠臣、奸臣和昏君。其实没有忠臣和奸臣，只有昏君。看似管理者高高在上，手握生杀大权，但其实权利早被信息提供者瓜分殆尽了。

神说，你扯远了。

我问：好吧，下一个问题是如何避免测试困难呢？

神说，你觉得是大的系统容易测试还是小的系统容易测试？

我说，当然是小的系统容易测试。

神说，那么，让系统尽可能的小。

我说，现在一个普通游戏都要好几个G。

神说，第一，让需求受控。这是一项很重要的管理工作，如果没有很好的完成这项工作，那么是管理上的失败。

我说，这似乎很困难，因为客户总是在要求我们加功能，而有些功能确实是很重要的。

神说，如果在项目后期要求增加功能，而这项功能又是必需的，那么实际上是在告诉我们需求分析出现了问题，出现了需求遗漏。而一项功能如果终因为各种原因其实不能使用，那么也是需求分析出现了问题，出现了需求冒进，脱离了实际情况。

神说，要控制需求的增长，需要决策者、需求分析人员和客户来区分某件事对客户来说真的是必需的，需要价值驱动。

我说，第二呢？

神说，第二，不要试图在软件中处理所有的可能情况。

我说，这个我有印象，我们需要向新系统中导入遗留报表，由于遗留数据跨越十年，所以存在很小一部分不规范的网页，如果在程序里包含对所有报表的处理，那么是相当困难的事情，后我们选择了手动处理这部分数据。

神说，第三，代码质量。好的实现永远是简洁的代码，要尽量减少代码的复杂性。两个具有相同物理规模的程序在内部复杂性上可能有极大的不同，而这终会是决定测试工作难度的主要因素。

我说，我们可以通过增量构建，不一次做所有事来控制代码的复杂性。

神说，此外要注意组件之间的分离，特别是多团队协作的项目。

我说，是这样的，对于大型项目，往往会划分以模块为单位的小组开发，小组之间、模块之间要尽量减少依赖和不必要的沟通，因此代码可以有冗余，每个开发小组都要各自独立，有自己的分析人员、开发人员和测试人员。

提到增量构建，我又有了新的问题。

我问：我们现在采用迭代式开发，那么每次迭代完成后对客户的演示能不能算是用户验收测试呢？

神说，演示不是测试。

我说，客户触摸到了真实的系统，直观了解到了系统的功能和使用方式，获取了系统信息，然后进行反馈，这可以看作是部分用户验收测试。

神说，对客户来说，如果没有真正的使用该系统，那么没有进行测试。此外，客户获取的信息难道不是你们准备好的吗？

我说，是这样，演示之前我们会进行很多准备工作。

神说，实际上是在准备客户能够获取的信息。

我说，那么理想的迭代开发应该是持续部署？

神说，持续部署和持续增量使用。