在监控过程中，首先要相信项目组自身的能力，假定他们有能力完成这些工作，这样工作就简单了，也变得可以操作了。
首先，查阅这些文档，大致看看，有没有明显的问题。其次，应该检查这些文档的评审记录，看看相关的人员是否参加了该评审，都发现了什么问题，大家的意见和建议都有那些。最后，看看所有的发现的问题是否都得到了解决，文档是否按照解决的方法进行了修订。
在监控的过程中，默认参与评审的人员技术能力都符合要求，这样只需要关注评审的过程就可以控制质量了。但是，如果有证据证明，评审的人员或者组成不符合要求，作为监控者应该宣布该文档的评审无效，需重新进行评审，以解决问题。但是，使用这项权利的时候要小心，而且要充分论证，否则会扰乱项目组的正常次序。
测试的相关文档是否都按照项目目前的实际情况进行了更新，并严格遵照执行?
经常会听到一句话就是：计划赶不上变化，这个问题就是冲着这句话来的。我在讲课的过程中问过很多人这样一个问题：不做计划，直接做事情行不行?至今我还没有遇到一个说行的。但是，如果计划和行动不同步，这个和没有计划又有什么区别?
项目中有各种各样的理由告诉你，我没有同步计划是合理的，但是我们的要求一定是必须有计划，而且必须严格遵照执行，这才是降低系统风险的唯一合理方法。
项目先前定义的测试范围在后续的计划、方案中是否有遗漏?
在测试初始期我们一直强调测试范围的必要性，在测试实施阶段还需要检查前期规划的测试范围是否在后续的计划活动中覆盖完全了，只有计划中完全的覆盖了所列的测试范围，才能保证系统的质量。
项目的测试过程是否按照公司预计的测试过程执行?
在测试实施阶段，还需要了解测试人员是否按照公司要求在执行所有的测试活动，但是要在短时间内了解，手段只能是听测试经理陈述他们的测试过程，再加以判断。如果公司有SQA人员，工作就相对简单了，只需要到配置管理库中找到SQA的检查报告，这些疑问就一目了然了。
3.测试结项期
在这个阶段，主要的测试工作已经进行完毕，最终的发布版本也已经准备出来。测试经理开始书写最终的测试报告，申请发货。
作为测试的监控者，这个阶段的主要任务就是评估软件产品的质量，依据已有的数据评估测试工作是否做到位，产品是否可以发布。
在这个阶段，应该如何进行监控，问些什么问题?
测试中发现的缺陷趋势曲线是否处于收敛状态?各个分模块的缺陷趋势曲线是否基本一致?
测试完成后，判断产品是否能够发货的一个重要条件就是：缺陷趋势曲线处于收敛状态，并且持续一段时间，表示系统处于稳定状态，满足发货条件。
那为什么还要看各个分模块的曲线是否一致?因为，有的系统比较庞大，有可能某一个局部的缺陷曲线还没有处于收敛状态，但是整个系统的缺陷趋势图已经把这个信息掩盖掉了。所以，还需要分别看一下各个模块的趋势曲线，确保系统的每一个部分都处于稳定状态，这样发货的风险才能降到最低。
是否有评判产品能否发货的文字性材料?
文章来源于领测软件测试网 https://www.ltesting.net/
