到12月时，除了之前的15个缺陷，他们又发现了138个缺陷。新增的测试工作得到了回报。接下来，对triggers（触发器）图表进行复查。在此之前，单个的功能triggers（触发器）构成了整个测试的全部（百分之百）。虽然计划的时间被延长了，但由多功能triggers（触发器）-- sequencing和interaction暴露的缺陷增长到了总数的37%。此外，我们通过系统测试的triggers（触发器）—recovery/exception（恢复/异常），发现了7个缺陷。测试场景由简单场景发展为更复杂的场景，从而发现了更多的缺陷。
在workload/stress和software configuration上还需要说明两点。由于测试执行方面的限制，没有发现新的缺陷。同时，由于缺少资源，这个结果被认为是可以接受的。
小结 在已延长的测试周期临近结束时，产品比8月份表现出了更强的稳定性。大部分的缺陷都已被发现，当然可以预计得到还会有很少量的缺陷逃逸到外部。事实上，它们还是被这个团队发现了。1月份报告了4个缺陷，其中的一个是build（构建）问题。然而，如果在8月份他们并没有做ODC评估，产品照原计划发布，那么九月和十月的测试所发现的缺陷很显然会对用户产生影响。用户满意度势必会降低，对团队开发高质量产品的能力失去信心。此外，开发团队还会变成“救火员”的角色。相反，这个团队利用了ODC的分类缺陷数据，评估了测试的有效性。在随后创建的测试计划中明确了目标，在之前缺少的sequencing测试中使用多功能场景。这些步骤都可能提高测试效率，同时降低弱点，让开发团队向用户交付一个稳定的、高质量的产品。
正如前面所提到的一个重要的方面，ODC提供的是基于数据的判断的支持。这个评估花去了一个小时的时间，随后决定扩大测试的范围，而这个决定是在客观的数据基础上做出的。一旦团队复查了图表中列出的ODC属性，有关产品是否准备就绪的争议就不会再有了。团队有了下一步的决定，有了要采取的应对措施，经理就不会再被两个对立的观点搅得痛苦不堪了。这些图表清晰地表现出了软件的状态，以及采取的措施，对团队来说，它们都是显而易见的。
这次的经历使开发团队相信，在测试期间不用花太多的时间和精力去精确地度量过程和强调风险。尽管是个小型团队，但对分类缺陷的数据评估可以很快就完成了，并采取相应的措施以避免潜在的灾难性的情况发生。最重要的是，从用户那里收集到的反馈表明这个版本是最稳定的版本！
Conclusion
总结
我们描述了三个不同产品的项目团队使用ODC的经历。通过使用ODC，每个团队都达到了提高测试效率的目标，同时对组织资源造成的影响也是非常小的。在所有三个项目中，他们在采用ODC之前已经收集并使用了缺陷相关的信息，而ODC能够让这些团队利用丰富的缺陷信息集，以一种客观的方式，来改进各自的产品质量。
第一个案例是一个高质量的产品，其目的是减少客户报告的缺陷，以此提高客户的满意度，同时降低质保的费用。通过对这些引起客户报告的潜在问题的确定，测试的有效性得到了提高。来自于逃逸缺陷的分类triggers（触发器），为测试和开发的某个具体区域的改进提供了必要的依据。这个团队所采取的措施其重点是加强测试计划，改进FVT培训，增加对已确定模块的回归测试，以及提高文档的质量。
第二个案例使用了在功能和系统测试数据中发现的缺陷来提高测试的有效性。这个研究列举了一个减轻进度压力的例子，通过ODC的分类缺陷，表明产品的进度充分，足以进入到下一步测试中。团队能够早于计划的时间开始系统测试，得益于ODC评估提供的信息，它表明团队已经达到了早期活动的退出标准。与第一个案例相似，这个团队也确定了一些薄弱的测试区域。随后，他们针对这些区域采取了具体的措施。他们实施的措施包括使用代码覆盖工具和功能测试用例的ODC分类，来确保他们所需的测试场景有足够的覆盖范围。
第三个案例描述了一个拥有很少资源的小团队，他们对测试存在的具体不足进行确定，并从中受益。这个团队使用的缺陷信息是在项目发布前不久在内部发现的。产品发布前，他们针对需要改进的功能测试，使用了ODC来确定多功能的测试场景。这样，团队能够快速地评估测试的效果并实施正确的措施来加强他们的目标triggers（触发器）。
ODC数据收集可以在软件开发过程中的任意点开始。所有的三个案例都提供了这样的例子，他们分别在软件生命周期中不同的时间点上对ODC分类的缺陷进行分析，并从中获益。而他们实施的改进措施都是合理且可行的，也不需要为实现提高测试有效性的目标投入大量的资源。
除了此处所表现的ODC的积极影响外，还有很多不容易度量的结果，但尽管如此，我们还是从中得到了很多的收益。我们的测试人员和开发人员身上产生了微妙的变化，比如他们的技能都提高了，因为现在他们能看到自己的工作是以一种新的客观的方式进行的。测试人员学会了用复杂的triggers（触发器）来考虑测试用例。他们会根据预定计划的阶段查看当前进度的趋势，也更加警觉于这些趋势里出现的任何偏差。他们变成了缺陷triggers（触发器）的比较能手，而这些triggers分别暴露了用户发现的和他们自己的测试所发现的缺陷。测试人员增加了测试有效性方面的知识水平，从而带来了更好的产品质量和更强壮的过程。最终，这些增长的知识生产出了质量更高的且开发费用更少的软件 -- 一个所有的软件组织想努力达到的目标。
Appendix A: Scheme version 5.11 for design and code
附录A：针对设计和编码活动的分类表 版本5.11
更多的信息和例子请参阅http://www.research.ibm.com/softeng。
提交缺陷时的分类属性：
Activity（活动）—指实际（软件开发过程）的活动。例如，在系统测试阶段，当你点击一个“选择打印机”的按钮时，出现了一个缺陷。虽然处于系统测试阶段，但对应的活动应为功能测试，这是由于此缺陷是通过执行一个“功能测试类型”的活动发现的。
Triggers（触发器）—触发缺陷出现的环境或条件。它的定义更类似于一种“测试类型”。
Impact（影响）—逃逸到外部的缺陷对用户产生的影响或开发过程中未发现此缺陷的影响。
