Rational Application Developer在开发周期的开始阶段是最有用的，因此让我们看看你主要在开发周期最后应用的工具是如何提高过程的成熟度的。这将指出这些概念实际上是多么通用。
为了证明我的观点，我为测试过程建立了近似于待检查的模型的一个成熟度模型（见附录B：测试过程的成熟度模型）。
当你的步骤需要多次重复时，自动化工具是最有效的。但是在初始级别，没有可重复性。你的测试是特别的，没有任何记录，也没有任何东西需要自动化。
在第2级，当你把你的测试步骤和环境写入文档时，你有了你可以自动化的基线。随着你在成熟度谱上的推进，达到第三级，你继续在开发和测试团队中介绍详细定义的标准。这使得你能够创建一个开发，发布工程和测试都可以使用的自动化测试基础设施。由于更多人正在从中受益，你将从自动化中获得更多价值。
如果你一直运行你的自动化测试，你将获得关于测试时间的数据，产生的典型问题，以及影响你的效率的因素等方面的信息。这是你能够进入到第四级，你将可以更好地管理你的测试时间表和错误率——甚至可以预报发布时间。
在第五级，你进行的是最优化。你可以把其他应用链接到你的自动化测试基础和测试框架上。你还可以结合一些应用，它们可以自动跟踪代码的变化，跟踪测试覆盖，提交错误，检查代码外形和存储使用，等等。在这一级上，你组织中的更多人可以获得更多特性的更大好处并实现更多目标。换句话说，你的成熟等级越高，你将发现更多人利用工具的优势。而他们使用工具越多，他们进入下一个成熟等级就更容易。
无论你处于哪个等级，你可以建立一个协作的和连续不断的改进环境——一种工具和过程成熟度等级间的最优关系。（如果需要关于如何更快推进成熟度等级的建议，请参看附录C）。
工具实施中的一个重要因素是决定在何处引入它：能够展示工具的全部能力和价值的最佳“第一项任务”是什么呢？我开发了一种技术来帮助你回答这个问题。
作为一个例子，让我们再回到测试自动化工具。向自动化的实现投资并不便宜，而且你需要一定的头脑和技术来取得成功。这就是为你的自动化工具认真选择合适的“任务”的重要性所在。我用来决定引入新的工具的时机的步骤如下：
- 定义一个好的测试的应具备的品质。
- 确定引入成功的标准。
- 确定你可能想要使用工具的所有领域。
- 根据成功的标准将这些领域排序。
- 当你向每一个领域引入工具后，将结果制表；决定你在何处取得最大收益并据此调整优先级。
- 根据你制定的图表优先级清单，管理你的自动化资源。
为了进一步说明，让我们按照上述六个步骤引入自动化测试工具。首先，下面是一个好的测试的标准（这不是一个无遗漏的列表，仅是一个示例）。
- 测试可以运行三次以上。
- 测试可以在多个平台和环境下运行。
- 测试将是每日“健壮性回归套件” 4 的一部分。
- 自动化安装和退出清除步骤在每一次新的建立之前能够运行。
- 测试将存在于一个“高通讯/高代码变化”的区域。
- 测试将存在于一个带有多个功能点（高集成度点）的代码区域，该区域被多个开发者所使用（高风险）。
- 测试将复制一个需要几个高级测试员来运行的人工回归套件；它将只需要一个初级测试员来运行。
- 测试将覆盖一个带有若干与之有矛盾的缺陷的领域。
- 这包括了从带有集成点的领域到带有若干个与之有矛盾的缺陷的领域（高风险）。
一旦你理解了这些好的自动化测试的大体标准，你就可以创建更为具体的成功标准然后把它们与潜在的实现领域作比较。
比如说，我要自动化下列工作：
- 建立我的团队每天都要在每个程序版本上运行的验证测试
- 一个人正在工作的产品上的新代码
- 维护发布上的回归测试集
- 经常变化的界面的接受测试
- 在所有外语机器上的健壮性测试
我将在我的最重要成功标准之外评定这张列表上的每一项：
- 发布中的测试周期数
- 人工测试中涉及的人数与自动化运行中涉及的人数之比
- 产品稳定性：我可以在不进行大量自动化测试脚本重写的情况下实现我的目标吗？
- 自动化实现需要的时间与人工测试运行需要的时间的比较：如果人工测试只需要十分钟来建立和运行，投入几个月的时间编码实现自动化还值得吗？
以我的情况，我认为没有必要弄得太精确。我分别使用了25，15，10和5作为我的评估界定数据。表2记录了结果。
