要考虑企业组织的成熟度和测试项目的特性。一般来说，测试过程包含下面几个阶段：测试计划和控制、测试分析和设计、测试实现和执行、测试出口评估和报告以及测试结束活动。
测试过程定义中，需要明确每个测试过程阶段的输入和输出、每个测试阶段的主要测试活动以及每个测试阶段中的质量检查点。明确定义软件测试过程以及相关的测试活动和输出，可以从制度上保证测试工作的顺利进行，并且可以有针对性的进行测试活动的控制。软件开发的产品质量是通过整个开发过程的质量控制来保证的。同样，测试质量也需要测试过程质量来保证。
（3）完善以前版本相关文档
收集和整理项目以前版本的相关文档，包括开发文档和测试文档。从测试的角度来说，有两方面的内容：一是学习以前的相关软件需求和设计文档（可能是已有的，或者通过开发团队收集和整理的文档），来了解软件的主要功能和实现方式；另一个是整理和收集测试相关的文档，比如每个版本的测试计划、概要测试用例、详细测试用例以及以前版本的缺陷信息等。
假如对每个功能进行全面的分析，需要花费巨大的人力和时间成本，这可能是不太现实的。我们的经验是和开发团队合作，召集各个领域和应用方面的技术专家，来对以前系统进行需求方面的文档化，至少对每个功能特征进行部分的描述，同时对一些复杂的功能接口、用户接口等进行详细的需求分析，形成比较详尽的系统需求文档。
针对测试文档，根据前面得到的一些基本文档提供的信息，分析软件的主要功能和重要功能，提供一些测试用户场景以及它们的输出预期。也可以通过探测性测试，得到软件的一些表现行为和结果输出。将这些用户场景和测试输出等进行文档化，作为后续项目测试的基础，也可以作为回归测试的输入和重点。
（4）软件新增功能的文档化
对新增加和升级的功能特征进行文档化，从确定开发和测试的系统版本开始，我们需要对每个增加的功能、升级修改的功能进行详尽的需求文档化，作为后续开发测试活动的参考和基线。这样，可以在后续的开发设计、测试设计等方面拥有共同的输入和参考点。这对于系统的研发非常重要，这个环节没有做好，项目的开发将一直处于混乱状态，例如：系统需求不明确、开发条目不清晰、测试输出预期没有标准等，无法保证项目产品的质量。
（5）基线化一个测试版本
确定一个固定的系统版本作为进行后续开发和测试的基础。所有项目的利益相关者需要在这一点上达到共识：为什么产品的开发是基于已经存在的软件系统之上？然后选择已有系统的一个版本作为新开发的基础，并且它是唯一的进行后续开发测试的版本。
固定后续开发和测试的版本，可以更加直观的来跟踪缺陷。通过对已有系统代码的升级或修改，可以判断在新的软件中某个现象是否是缺陷。在碰到输出结果存在异议的时候，通过各个领域的专家来验证到底是新系统引入的新缺陷，还是旧系统中本来存在的问题。通过该策略，大家既可以对系统的输入和输出达成一致，也可以作为对原有系统需求收集和文档化的手段之一。
（6）基于风险的回归测试
对于中途接手的项目测试，回归测试将是测试过程中的一个重要关注点。因此，如何选择回归测试用例，来提高测试的效率和有效性，是测试团队面临的一个重要问题。
通过前面提到的各种建议，可以对测试团队、测试过程和文档化方面进行改进，从而有利于回归测试用例的选择。回归测试用例的选择，基于测试风险而展开将是一个有效的手段。下面的实践经验可以作为一个参考：
● 分析软件中什么功能是客户最经常使用的？
● 什么功能对客户而言是最重要的？
● 什么功能在以前版本中发现的缺陷是最多的？
● 新增加的功能或者升级，对原来的什么功能和模块的影响是最大