自动测试工具通常具有某种测试结果报告机制，能够维护测试日志信息。有些工具产生彩色编码的结果，绿色输出表示测试通过，红色输出表示测试失败。这种测试日志输出改善了测试分析的简单性。大部分工具还可进行失败数据和原始数据之间的比较，自动指出两者之间的差别，再次支持测试输出分析的简单性。内部开发的测试工具能够利用不同方法区分测试是否通过。
为获得最大成效，要像核查准入标准一样验证准出标准，这一过程也应该自动化。准出标准描述的是软件已经充分地测试了。由于测试资源有限，测试预算和分配给测试项目的测试工程师人数有限，最后期限很快来临，因此测试工作同样必须有一定的范围限制。测试计划必须说明何时完成测试。然而，如果准出标准表述模糊或者定义含混，测试团队将无法确定测试工作完成的时间点。测试可能会永远进行下去。
测试完成标准可能包含这样一份声明：所有按需求定义的测试过程必须成功执行，没有任何重大问题，这意味着所有高优先级的缺陷必须由开发部门解决，并通过测试团队成员进行回归测试验证。有了这一点，加上本书中讨论的其他所有建议，则对系统满足所有需求而没有主要的缺陷将更有把握。
作为一个简单的例子，应用程序的准出标准可能包括下面一条或多条声明：
已经执行了那些为了确定系统是否满足特定功能和非功能需求的测试过程。
系统是可接受的，提供了所有等级（1、2和3共3个等级，分为重大、紧急和高优先级）的软件问题报告，将其作为测试结果，并且都已经解决了。
或者
系统是可接受的，提供了所有1级和2级的软件问题报告（重大问题、紧急问题），并已经解决了。
或者
系统是可接受的，提供了1级和2级（重大问题和紧急问题）的软件问题报告，并记录为测试结果，都已得到解决，还有90%的级别3的问题报告也得到了解决。
开发人员同样需要关心系统验收标准。测试团队需要先跟开发人员就准入和准出标准进行沟通，然后提出测试计划审批申请。如果可以，组织内的测试准入和准出标准应该标准化，应该基于已通过多个项目证实过的标准。
系统可以包含一些缺陷，这些缺陷将在以后的发布或补丁中加以解决。在产品上线之前，测试结果分析有助于确定是哪些缺陷需要立即修复，哪些缺陷的修正可以延后。例如，一些缺陷可能重新归类为增强功能，可以在以后发布的软件里加以解决。项目经理或软件开发经理和其他变更控制委员会成员一起决定是修复缺陷还是发布有缺陷的软件产品。
作为准出标准的一部分，要评估一些额外指标（要了解更多关于测试指标的讨论参见第8章）。比如：
回归测试期间，在先前可工作的功能中发现缺陷的速率（这意味着缺陷的修复破坏了以前可工作的功能）是多少？
缺陷更正的频率是多少，是否意味着重测失败，缺陷应该修复？
新开放的缺陷率是多少（平均值）？缺陷的开放速率应该随着测试阶段的进行而减小。如果不是这种情况，就意味着有更大的问题，需要分析。
当应用程序或产品是可接受的，其当前状态足够发布或上线，满足了准出标准，那么即使有可能存在比已发现的缺陷更多的缺陷，也可认为测试完成了。
确定软件质量和判断准出标准是否满足的另一个方法是可靠性模型，这将在第2.3节介绍。
一旦正式的软件版本满足了准出标准，软件只有对客户有用时才是成功的。因此，将客户的验收测试纳入测试计划中很重要。
重要的是，测试团队应建立软件完成和发布的质量准则。将这部分工作自动化是值得的。
