可以用同行评审来完成，没有一个是基于代码的。而且上边的例子中没有一个评价是穷尽的，必要时我们可以进行的其他评价。关键是我们输出一个交付产品（如需求文档），在我们能够正式称它是完备的并可被下一开发步骤使用之前，我们必须基于预期的特征对之进行评价。而进行这些评价需要比进行同行评审更加复杂的技术。
这就是评价和测试的关键所在。一个特征的预定义集合，尽可能被明确定义，用来对一个交付产品来进行确认。例如，当你在学校，进行了数学测验，老师会拿你的回答与预期答案相对比。老师不会仅仅说他们看上去也是合理的，或者他们更加准确。答案是9.87652，要么它对，要么不对。同时，老师也不会等到学期结束才将在课程早期交上来的进行判卷，在他们做出来之际就得到了测试。目前我们软件开发承担更加大风险，难道我们还可以有任何的不严格和不及时吗？
这些应当进行评价和测试的交付产品应当包括需求规格说明书，设计规格说明书、数据转换规格和数据转换代码、数据库设计说明书、培训资料、硬件/软件安装规格、用户手册和应用程序代码等等。当然这并不是一个完整的列表。问题的关键是，在你的项目生命周期中的每一个交付产品都必须被测试。
对于一个给定交付产品的评价和测试可能会延续项目生命周期的多个阶段。越来越多的软件组织开始从瀑布式模型向迭代式模型转变。例如，设计规格可能会经过三个迭代才能产生。第一个迭代定义体系结构—它是人工的还是自动的，是集中的还是分散的，是在线的还是批命令式的，是直接文件存储还是通过关系性数据库等等。第二个迭代则可能继续推动设计，来鉴别所有的模块和模块间的数据交换机制。第三个迭代则定义模块内部的伪代码。每个迭代都应当基于适当的特性来进行评价与测试。
评价和测试的类型必须是鲁棒的、坚固的。这包括对功能、性能、可靠性-可用性/实用性-可服务性、易用性、可移植性、可维护性和可扩展性等的验证，但绝不仅限于此。
总之，每个阶段的每个交付产品必须通过正式的、训练有素的技术来对适当的属性进行评价和测试。
二、在CMM中为什么要加入这个独立的KPA
由五个重要方面能说明必须有一个独立的软件评价与测试的KPA，即：
(1)评价和测试在促进向有纪律的软件工程过程过程的文化转变中的作用；
(2)评价和测试在项目跟踪中所起的作用；
(3)整个开发和维护在评价和测试部分的预算；
(4)评价和测试训练对软件交付时间和成本方面的影响；
(5)评价和测试对软件残余缺陷的影响。
将软件工业从一种手工(艺)匠方法向真正的训练有素的工程层次迈进实在是一种文化的转折、跃变。CMM的首要的而且也是最重要的目标是，建立一种机制来推进向软件工程的文化改变。但是一个文化不可能发生激烈的改变，除非你深刻理解改变的重要性。必须全面理解向新的文化改变所能给我们解决的问题。最后这一点，将使我们引导我们来讨论测试在这一加速向训练有素的文化改变中所起的作用。
在1960年代后期，IBM是第一批开始应用正式软件工程技术的组织之一。一开始使用的是Dijkstra支持的技术。具有讽刺意味的是，并不是由软件开发人员发起这项努力的，而是软件测试人员。这一创始性工作是在Poughkeepsie实验室进行的，属于Philip Carol领导的面向测试的设计项目。
Phil是软件测试技术工作组(SW Test Technology Group)的一个系统测试工程师。这个工作组主要负责定义软件测试技术和工具以用于整个公司。大概在30年以前，他们就开始意识到你不可能通过测试将质量注于代码中。你需要像考虑测试过程一样也得考虑分析、设计和编码