可跟踪性能够收集关于单独的需求和受到需求变更影响的系统的其它部分,包括设计,编码,测试和帮助镜像等等.当测试人员知道需求发生变更时,他们能够对受到影响的部分作出相应的调整和修改.
当个别的需求能够进行评审时,就要尽可能的使用上述的特性对需求进行测试和验证.捕获与需求相关的缺陷,尽早的识别出它们,能够防止错误的需求产生与其一致的设计和实现,那时发现和改正缺陷是非常困难和代价昂贵的.
开发软件需要好的组织,计划,跟踪和测试的每个特性,通过这些步骤之后这一系列特性都比略述了和量化了.
第三种．需求完成后尽可能早的设计测试流程
就像软件开发工程师根据需求文档来设计详细文档一样，测试部门也同时根据需求文档来设计测试流程。在有些公司，测试流程的制定往往被推迟到软件已经集成并交付给测试部之后才开始，这是由于一方面是没有时间，另一方面是没有适合测试部制定测试流程的特定的需求文档。这种做法会产生下面这些问题：需求文档在软件开发后期有可能发现遗漏或者错误，软件实现出现了不能满足需求的问题，不可测试性和产生不完善的测试流程。
测试流程的设计在需求阶段就实施，不要等到软件开发阶段才开始，这样做可以给需求说明文档的开发过程带来好处。在测试流程的开发过程中，当测试人员在一定的层次上试图通过使用一系列的输入数据与系统进行交互时，需求文档中的一些观点，遗漏的地方，不正确的流程和其它错误的地方都有可能被发现。在这个过程中，需求就要满足各种各样的场景，同样通过交互可以明确所有场景中的某一清晰的路径。
如果需求中的一个问题没有被发现，那么需求中就需要去对这个问题进行重新设计。在开发过程中越早的进行这样的修正不会相互作用，这个修正也可能非常小的影响软件的设计和实现。
在第一条中我们已经提到过，早期发现的错误修改的成本都较低。如果一个缺陷是在开发过程的后期才被发现，所有风险承担者都必须修改需求，设计和代码，这将影响到预算，进度，不家可能影响员工的士气。然而，如果缺陷是在需求阶段发现的，修改它是一个很简单的事情，只要修改需求文档就行了。
参考验证需求的可测试性，通过测试流程的制定来识别出需求中的错误和遗漏部分。如果没有足够的信息或者说明书中提供的信息太含糊不清了，不能使用它来创建完整的测试流程和使用相关路径的相联系的测试用例，那么说明书就可以被认为是不可测试的，并且它并不适合软件的开发。对一个需求的测试能否制定是一个有价值的检查和需求改进完善过程中的一部分。不过也存在特例，需求也许不能立即使用有序的或手动的执行测试来被验证。这种例外需要简要的说明。例如：实现一个像“所有的数据文件要使用记录在案的方式保存三年”的需求就不能立即的被验证。然而，它就需要改正，持续和跟踪。
如果一个需求不能被验证，那么也就不能保存它能够正确实现。制定出包含数据输入的测试流程，一步一步的验证需求，了解每一个相应需求的预期输出，通过确认重要的需求信息没有遗漏能够保证需求的完整性，不要使需求复杂化，甚至不能够正确的实现和不可测试。越早的制定测试流程能够更早的发现需求中不可验证的问题。
在软件已经集成并交付给测试部之后再制定测试流程，要承担测试流程制定得不完整的风险，因为完成产品的测试周期的紧张的时间压力。这表现出以下几个方面：例如，测试流程也许缺少整体性，或者它没有制定全面，遗漏了一些路径或者可能产生测试结果的不同性的数据。结果是一些缺陷没有被发现。或者早期的需求描述得不够完善，没有提供必要的测试流程的定义，或者非常合适的软件开发过程。不完善的需求往往导致不完善的实现。
测试策略的制定可以以早期的软件需求的可测试性的评估为基础。当对需求的可测试性进行评审进，测试人员也许认为使用捕获或者回归工具是很好的方法，或者一些测试允许使用自动化测试方式。早早的确定这些有助于有充分的时间来评审和实施自动化测试工具。
还有另外一个例子：一些与需求相关的复杂的和各种的计算也许更适合使用用户测试驱动或者特殊的脚本来测试，在早期的评审阶段，这些方法就能够确定。在测试开始前测试驱动的开发和其它一些像测试准备活动需要额外的时间。
测试流程在需求定义阶段就制定带来了一些额外的负担，包括依据需求来制定测试流程的优先级，分配足够的人员和理解测试策略。这些通常都是代价很高的，如果可能的话，把每一个需求的测试流程都立即制定出来，这是因为时间，预算和人员的限制。理想状态下，需求和专业知识的专家和测试部门共同负责作为需求定义一部分的测试场景的创建，包括场景的输出（预期输出结果）。
测试流程的制定必须以迭代的实现计划为优先次序。如果存在时间限制，测试工程师第一个实现的应该是需求的测试流程的制定。他们可以制定出一个针对所有需求的测试流程的草案，以后再慢慢完善。
需求通常通过循环的评审和分析来达到最优。非常普遍的是新的需求的细节和场景表面的分类都是在设计和开发阶段。完美主义者也许认为所有需求的细节都是在需求开发阶段标识出来的。然而，实际上是项目期限的限制要求我们尽早的开始开发，完成需求近乎完美是极其罕见的。如果在开发过程中需求逐步完善，那么相应的测试流程也要做相应的完善。这就需要任何改变都要相互一致：他们可以认为是活着的文档。
在需求阶段，包括需求和测试流程都需要一个完善的过程，这就要求测试设计者和风险承担者做出有效的管理。参考第四条关于需求变更时所有风险承担者之间交流的重要性。
第四种．确保需求变更的交流性
测试流程是建立在需求的基础上，当需求发生变更时，应保证测试组成员都被告知了，这是很重要的。这看起来是很显然的，可是，令人惊讶的是测试流程在执行的时候往往和软件的实现相冲突，这是由于需求发生了更新，测试人员要对开发和执行测试流程负责任，而很多时候需求发生变更时去没有通知他们，这就导致了缺陷的错误报告和浪费必须的调查和保贵的时间。
下面有一些原因可以解释这个过程的减弱，如下：
1． 没有文档的需求。像产品或项目经理、客户或者需求分析员，这些人来指导开发人员去实现功能的改变，去没有和其他风险承担者达成一致，而且开发人员实现这些变更没有进行交流和保存成文档。这个过程就需要开发人员不论怎样或不论何时，当需求发生变更的时候要把它清楚的保存起来。通常通过使用变更控制簿，工程评审簿和下面讨论的其它相似的机制来处理。
2． 过期的需求文档。对于测试人员来说，另一个缺陷是部分的或者馈乏的配置管理会使测试人员使用版本过期的需求文档来制定测试计划和流程。更新需求时需要文档化，把它放入到配置管理中并且和相关人员进行交流。
3． 软件缺陷。尽管需求文档和测试文档都非常正确，可是开发人员也许不能够正确的实现需求。
在最后一条中，必须写缺陷报告。然而，如果需求变更过程没有被执行，那么很难去澄清上述的场景是否真的会发生。问题是发生在软件、需求和测试流程中，还是所有的过程中？为了避免陷入臆测之中，所有的需求变更都必须公开的进行评估，达到一致的同意和所有风险承担者之间的交流。
如果需求需要变更时，变更过程会引起连锁反应，影响到设计，编码和其它相关的文档，包括测试的相关文档。为了有效的管理这个过程，任何变更都应该置于配置管理的基线和版本中。
变更过程的概括是何时提出来的，如何提出来的，是谁提出来的和什么地方提出来的。这个过程需要指明的是变更请求可以在生命周期的任何阶段提出来，在任何类型的评审，走查，或者需求、设计、编码、缺陷跟踪，和测试活动中，或者其它阶段。
每一个需求请求都要经过变更控制会议通过并且使用变更请求表保存成文档，变更请求表是方便变更请求的包括必须信息的列表。建立变更控制会议有助于确保需求的任何变更和其它的变更请求符合指定的流程。变更控制会议检验了变更请求文档是合适的，已评估的和一致同意的；它所影响的其它文档（需求，设计文档等等）都被更新了的；并且所有风险承担者都被通知了。
变更控制会议通过包括来自产品管理、需求管理、QA人员，同样还有测试经理和配置经理的代表。变更控制会议必须建立在必要性基础上。所有风险承担者都需要依据优先级、风险和相关变更建议的均衡来评估地面需求变更。
分析提出的变更相关的和关键的影响是可执行性。例如，需求变更可能影响到整个测试文档，需要来增加测试环境的主要部分和花费数周的时间来扩充测试任务。或者由于影响到整个自动化测试系统，执行步骤也需要作相应的改变。在变更被通过之前，这些影响必须能够识别、交流和公布出来。
变更控制会议确定了变更请求的有效性、影响、必要性和优先级（例如是否要立即执行或者是否作为增进的文档保存到项目的知识库中）。变更控制会议必须确保变更建议、相关的风险评估和决策决定过程是可文档化的和相互交流的。
必须认识到任何变更建议的所有部分都会有助于风险分析和变更的减弱。一个有效的方法是使用需求管理工具来保证它的实施，和维护测试流程中的需求的可跟踪性一样，需求管理工具被经常用来跟踪需求变更的情况。如果需求发生变更时，变更就应该在需求管理工具中得到反映和更新，并且工具应当标记相影响的测试产物（和其它影响元素，例如设计、编码等等），因此相应的各自的部分能够更新他们的产品。
变更信息通过使用需求管理工具来管理，使得测试人员能够像变更对测试相关产物或测试进度表的影响一样，再次评估需求变更的可测试性。受到需求和实现变更影响的测试流程必须能够再次访问和更新。以前确认的缺陷也必须重新评定，以确定需求的变更是否使它们变成作废的。如果是脚本、测试驱动或者其它已经创建的测试机制，它们也要应做相应的更新。
一个明确的方便需求变更交流的和考虑到有效的测试计划的过程，对项目的效率是非常关键的。
