尽管没有达到FV的正式标准，但ODC提供的信息让团队相信项目已可以开始系统测试了。随后，系统测试团队取得了快速地进展。
分析外部缺陷，改进系统测试.? 图4也说明系统测试的大部分关注点都在workload/stress（工作量/压力）上。有超过百分之五十的缺陷是通过workload/stress（工作量/压力）测试发现的。图5展现了对前一版本的外部缺陷进行后续分析所产生的结果。图中的activities和triggers清晰的显示了用户暴露的缺陷较之内部测试所发现的，其对应的系统triggers（触发器）的范围更为广泛，特别是在software configuration（软件配置）上表现的尤为明显。因此，系统测试团队会复查他们的测试，以扩充他们的测试场景，特别是software configuration（软件配置）的区域。 
通过对外部和内部缺陷的分析，改进功能测试.? 随着FVT（功能验证测试）的完成，测试团队复查了ODC数据以寻找潜在的改进区域。图6、7和8突出了在未检查的情况下可能出现的潜在问题。 
图6展现了产品前一个版本的外部缺陷对应的defect type（缺陷类型）和qualifier（限定）。虽然checking类的缺陷并不是最大的一组，但其中有相当大的一部分是由missing（缺失）的代码引起的。图7展现了一个相同的表，但显示的是当前版本在内部发现的缺陷。这次，checking（检查）类的缺陷是最大的一组，而且其中的大部分同样是由于代码missing（缺失）引起的。图8则展现了qualifier（限定）均为missing的内部缺陷，以及它们的defect type（缺陷类型）和triggers（触发器），同时表明大部分因missing（缺失）检查造成的缺陷是由variation（变量）和sequencing（顺序）测试发现的。这说明低层设计的稳定性存在问题。
根据这次评估的结果，FV（功能验证）团队的成员们决定以提高发现“缺失检查”的能力为目标，重新复查他们的测试序列，特别是：
使用代码覆盖工具度量由功能测试序列获得的语句和分支覆盖率。测试人员在开发人员的帮助下利用输出的结果，来确定测试序列中的缺口和重复。
ODC的triggers（触发器）是良好覆盖率的保证，因此，可以根据它们对功能测试用例进行分类和分析。为了向2000年的悉尼奥运会提供最好的产品，IBM团队使用了这种技术作为一种确定方式，事先确定测试序列能否使用大范围的triggers（触发器）。获得此产品FV（功能验证）的测试序列的有效性评估是至关重要的，特别是随着时间的发展，测试用例的数量会明显地增加。
由评估引出的改进.? 几项致力于改进过程的措施都来自于ODC评估结果。在一个典型的发布周期内，仅仅在最后的几周或几个月里，才尝试对缺陷的修复进行优先级划分，往往会导致测试工作长期停滞不前，并超出实际需要的时间。图表9里面的数据指出，很多缺陷的严重等级都是3级，而通常会认为它们已足够严重，需要修复，但实际上它们还没有严重到让用户的系统崩溃的地步。尽管这些缺陷占了已提交缺陷总数的百分之八十，但是不可能把它们放在优先的位置。因此，我们在在缺陷描述中添加了一个新的属性“importance”（重要性）。基于对有多少工作会受此缺陷影响的考虑，提交人可以指定缺陷的重要性，以使这个缺陷能够得到快速的修复。 “重要性”有：
- 高重要性：阻碍了大量的测试工作，需要立即修复的—紧急。
- ?中等重要：阻碍了一部分测试工作，但同时还可以进行其他的工作，需要尽可能快的修复。
- 低重要性：最多阻碍了一到两个测试工作，可以继续进行工作，有时间的时候修改。
