过程。作为测试人员，由于测试需要接触软件开发的所有方面，他们对问题有更加彻底深入的理解。
正是这一对问题的深入认识并将这一问题明确有力地向开发人员指出推动了软件开发文化的迅速改变。随着改进的开发和测试技术的应用，IBM的OS操作系统的缺陷率在下一个发布降低了1/10。这确实是在短时间内产生的重要的文化变革，特别是这涉及到了分布在不同地域的近千名软件开发人员。
这种变化的加速除了对问题的重视的直接推动外，另一个推动因素是与测试有关的一些因素，即在测试过程和开发过程集成中的反馈环。随着开发过程的不断改进，评价和测试过程并行地改进以反映新的成功准则。随着开发不断使用新技术，他们直接从测试人员那里得到及时的反馈即他们究竟做的怎么样，因为测试人员就是专门基于新的尺度对交付产品进行确认的。
一个具体的例子是需求撰写改进技术的应用，需求必须是明确的、确定的、逻辑上是一致的、完备的、正确的。有关结构化分析方法和面向对象的方法的培训课教系统分析员如何来写一个好的需求。如果在他们刚刚写完第一个功能描述时就进行模糊性评审，那么他们写的下一个功能就会更加清晰明确。这种紧凑的反馈环—写一个功能、评价一个功能，有效地加速了其学习曲线。这样的话，过程从缺陷检测到缺陷预防转移的相当快速----他们正在写着清晰、不模糊的规格。
将这些经验与我们的整个软件工业做一个对比，结构化设计技术和面向对象的技术已经在25年前就可以应用了(是的，OO确实已经那么老了)，然而我们的时间的情况却远远落后于这些方法的最新技术发展水平。问题是除非组织理解了正在解决的问题，否则它不会全面接受或者全面理解一个解决方案（如：软件工程方法和技术），而集成的评价和测试正是问题理解的杠杆和关键。这里“集成评价和测试”被定义为将测试集成到软件过程的每一步中，它也是为掌握一个技术所需的必要的反馈环的关键部分。任何没有紧密反馈环的过程是具有致命缺陷的过程，因此评价和测量是加速文化改变的关键。
一个项目计划一般包含任务、关联、资源、进度、预算和假设等等。每个任务都应当输出一个良好定义的交付，且必须对交付产品进行验证以证明该交付产品是确实是完备的。如果你对任务输出的完备性进行评价和测试，那么你不可能准确地跟踪项目的真实的状态。
在决定一项实践应不应当是独立的KPA时，一个重要的实效因素是它在软件开发活动的预算和人员投入中所占的比重。如果在这方面越显著，那么它应当受到的关注应当越多。而软件测试在整个软件开发中所占的比重在一半左右。
集成评价和测试可以支持更多的活动并发从而进一步缩短进度。如果需求没有得到正式评价，就常会导致设计和编码活动产生对早期提交的功能范围和定义的大量修改。正是基于这一原因，用户手册和培训手册等工作直到对代码的测试都差不多了的时候才能开始。到那时，几乎没有人会对早期的系统定义有什么信任。
同样，没有很好定义的需求也不能提供足够的信息来支持测试脚本的设计，因此测试用例的设计和构建也只能等到编码做得差不多的时候才能开始。
根据这两种情况，可以得出目前开发过程是线性的：先需求、然后是设计、编码、接着是测试、编写用户手册。如果写的需求规格能够达到一个确定级的详程度(即：给定一个输入集和一个系统初始状态，你应当能够按照规格中的规则准确地确定输出和新系统的状态)，那么测试用例的设计以及用户手册的编写就可以和系统设计并行执行。这样同时也就缩短了系统交付时间。关键是要对规格需求进行正式的评价活动。
从中我们看到在CMM中加入这个独立的KPA是很有必要的。
三、结束语
通过以上的论述我们看到，
评价是对软件开发过程中所产生的各种系统规格和模型的集成性进行保证的活动，测试则是基于机器的对代码进行测试的活动。软件评价和测试的目的是确认(即：判断这是我们所要的吗？)和验证(即：这是不是正确？)每一个软件项目交付产品，并及时发现这些产品中的任何缺陷。
软件评价和测试包括识别需进行评价和测试的交付产品；确定需要执行的评价和测试类型；定义每个评价和测试的成功准则；设计、构建、执行所需的评价和测试；验证评价和测试结果；验证测试集全面覆盖既定的评价和测试准则；创建和执行回归库以用于在交付产品发生修改后进行重新验证；登记、汇报、跟踪发现的缺陷。
最开始进行评价的交付产品是软件需求，随后，大部分评价和测试是基于被确认的软件需求。