Laura Rose, 质量保证经理
2005 年 8 月 01 日
来自 Rational Edge：为了在软件开发业中更具竞争力，商业机构需要迅速发布高质量软件以适应变化的市场和技术。尽管自动化工具能够帮助完成这项任务，多数组织仍然依靠敬业的团队的巨大努力来获得成功。这篇文章解释了一种通过有效地使用自动化工具突破这种低效的模型的方式。
作为一个质量保证经理，我对覆盖了整个开发周期——从早期设计到自动化测试——的若干的产品负责。在产品发布以前，我安排内部客户使用它们以评估产品的完备性。
在我寻找分析Rational Application Developer的代码和检查工具的内部客户的过程中，我遇到了来自一个令人惊奇的抵抗源：我自己的开发团队。为什么？原因之一是我们的软件的成熟水平。
在能力成熟模型Capability Maturity Model (CMM)的起源地——卡内基梅隆大学的软件工程学院，研究人员是这样解释这种现象的：“成熟水平是一个详细定义的，在实现一个一致、成熟的软件过程中的成熟状态。” 1 随着你实现成熟框架的每一个级别，你的组织能力提高了。但是很少的软件组织拥有合适的系统化的有效改进项目来推进到下一个成熟水平。
这篇文章解释了如何使“下一个水平”的实现变得容易一点，提供了向你的开发过程中成功引入自动化工具的要点和技术。
尽管CMM最开始是被美国国防部指定用来帮助限制软件卖主的，目前它已在世界范围内被军事，贸易和政府组织所使用。它已经被证实不仅可以减小与开发项目相关的风险，还能够提高效率和整体产品质量。模型有五个组织成熟等级，如图1所示。
图1：软件过程成熟度的五个等级
表1说明了五个成熟等级的特点，参照是模型最近的文档CME / SEI-93-TR-24。
表1：成熟等级的特点
|
尽管这些概念都很简单，它们的执行却不然。大多数软件组织仍然停留在第一级。不到百分之五的组织在努力达到第四级或第五级。通常，提高一个成熟度等级需要两年半（这指的是你很勤奋并对任务很严格的情况下所需要的时间）。我们失败是因为我们不能摆脱旧的习惯，特别是当时间紧迫的时候。这意味着我们实际上永远也不能经历和体会我们的质量初始情况和过程的全部结果，于是我们不相信那些结果是对的。
  |
|
如果你已经意识到在你的开发周期中的一或多个方面使用自动化工具的需求，并已经评估了你的目标和为你的需要选择了合适的工具， 2 使用CMM的等级作为指导可以帮助你成功部署工具。
必须记住的三件事情：
- 工具的设计是为了使过程变得容易；如果你不遵从那个过程，那么工具对你来说是没有价值的。
- 时间是敌人。如果看不到工具的价值，人们就不会把他们宝贵的时间投入到学习如何使用这些工具中。
- 工具的有效性将与你的组织的过程成熟等级直接成比例。你的成熟等级越高，那个工具的投资回报就越高。
正如我前面提到的，尽管我成功地吸引了很多IBM团队使用Rational Application Developer——我们的静态分析和检查工具, 我自己的开发团队却抵制这一工具。他们了解产品，也同意使用它可以带来好处，甚至还同意使用工具。但是，最后，他们从不安排时间来使用它。我着手找出原因，采用了如下的步骤：
- 确定你想要实现的工具（在本例中，是Rational Application Developer）。 3
- 确定你的工具支持的过程（对Rational Application Developer来说，过程是代码检查）。
- 在附录A的检查过程（或为你自己的目标，工具和技术集合设计一种特殊连接方式）中使用成熟度等级清单来评估你的开发团队的成熟度现状。
- 使用相同的清单发现其他使用你的产品的组织的成熟度状况。
我的发现使我既惊讶又尴尬。和很多软件组织一样，我的团队处于第一级（没有适当的过程），而其它团队有形式上的代码检查。概括来说，他们在检查和评价方面有更为成熟的过程。这就是他们能够立即发现工具将会提供的价值的原因。与之形成对比地，我的团队没有看出为了支持一个团队成员不会首先选择的过程而投入时间，资源和开发周期的价值所在。
在找出原因以后，我决定把开发精力集中到更为成熟的组织上。我还下决心要在检查和评估方面训练我的开发组织。我想，一旦检查成为常规并遵循一个规则的时间表，我的团队就将会发现Rational Application Developer的价值。尽管如此，在团队成员真正体验到工具的价值和对投资的回报之前，他们将会继续抵抗。
图2展示了我的发现的时间进程和概况。尽管我在自己的组织内部部署Rational Application Developer上不是100%的成功，这仍是一次很好的学习经历。
图2：时间进度概况
Rational Application Developer在开发周期的开始阶段是最有用的，因此让我们看看你主要在开发周期最后应用的工具是如何提高过程的成熟度的。这将指出这些概念实际上是多么通用。
为了证明我的观点，我为测试过程建立了近似于待检查的模型的一个成熟度模型（见附录B：测试过程的成熟度模型）。
当你的步骤需要多次重复时，自动化工具是最有效的。但是在初始级别，没有可重复性。你的测试是特别的，没有任何记录，也没有任何东西需要自动化。
在第2级，当你把你的测试步骤和环境写入文档时，你有了你可以自动化的基线。随着你在成熟度谱上的推进，达到第三级，你继续在开发和测试团队中介绍详细定义的标准。这使得你能够创建一个开发，发布工程和测试都可以使用的自动化测试基础设施。由于更多人正在从中受益，你将从自动化中获得更多价值。
如果你一直运行你的自动化测试，你将获得关于测试时间的数据，产生的典型问题，以及影响你的效率的因素等方面的信息。这是你能够进入到第四级，你将可以更好地管理你的测试时间表和错误率——甚至可以预报发布时间。
在第五级，你进行的是最优化。你可以把其他应用链接到你的自动化测试基础和测试框架上。你还可以结合一些应用，它们可以自动跟踪代码的变化，跟踪测试覆盖，提交错误，检查代码外形和存储使用，等等。在这一级上，你组织中的更多人可以获得更多特性的更大好处并实现更多目标。换句话说，你的成熟等级越高，你将发现更多人利用工具的优势。而他们使用工具越多，他们进入下一个成熟等级就更容易。
无论你处于哪个等级，你可以建立一个协作的和连续不断的改进环境——一种工具和过程成熟度等级间的最优关系。（如果需要关于如何更快推进成熟度等级的建议，请参看附录C）。
|
|
工具实施中的一个重要因素是决定在何处引入它：能够展示工具的全部能力和价值的最佳“第一项任务”是什么呢？我开发了一种技术来帮助你回答这个问题。
作为一个例子，让我们再回到测试自动化工具。向自动化的实现投资并不便宜，而且你需要一定的头脑和技术来取得成功。这就是为你的自动化工具认真选择合适的“任务”的重要性所在。我用来决定引入新的工具的时机的步骤如下：
- 定义一个好的测试的应具备的品质。
- 确定引入成功的标准。
- 确定你可能想要使用工具的所有领域。
- 根据成功的标准将这些领域排序。
- 当你向每一个领域引入工具后，将结果制表；决定你在何处取得最大收益并据此调整优先级。
- 根据你制定的图表优先级清单，管理你的自动化资源。
为了进一步说明，让我们按照上述六个步骤引入自动化测试工具。首先，下面是一个好的测试的标准（这不是一个无遗漏的列表，仅是一个示例）。
- 测试可以运行三次以上。
- 测试可以在多个平台和环境下运行。
- 测试将是每日“健壮性回归套件” 4 的一部分。
- 自动化安装和退出清除步骤在每一次新的建立之前能够运行。
- 测试将存在于一个“高通讯/高代码变化”的区域。
- 测试将存在于一个带有多个功能点（高集成度点）的代码区域，该区域被多个开发者所使用（高风险）。
- 测试将复制一个需要几个高级测试员来运行的人工回归套件；它将只需要一个初级测试员来运行。
- 测试将覆盖一个带有若干与之有矛盾的缺陷的领域。
- 这包括了从带有集成点的领域到带有若干个与之有矛盾的缺陷的领域（高风险）。
一旦你理解了这些好的自动化测试的大体标准，你就可以创建更为具体的成功标准然后把它们与潜在的实现领域作比较。
比如说，我要自动化下列工作：
- 建立我的团队每天都要在每个程序版本上运行的验证测试
- 一个人正在工作的产品上的新代码
- 维护发布上的回归测试集
- 经常变化的界面的接受测试
- 在所有外语机器上的健壮性测试
我将在我的最重要成功标准之外评定这张列表上的每一项：
- 发布中的测试周期数
- 人工测试中涉及的人数与自动化运行中涉及的人数之比
- 产品稳定性：我可以在不进行大量自动化测试脚本重写的情况下实现我的目标吗？
- 自动化实现需要的时间与人工测试运行需要的时间的比较：如果人工测试只需要十分钟来建立和运行，投入几个月的时间编码实现自动化还值得吗？
以我的情况，我认为没有必要弄得太精确。我分别使用了25，15，10和5作为我的评估界定数据。表2记录了结果。
表2：自动化表项的成功标准等级评价
|
根据表2的结果绘图（见图3）使得我可以比较容易地发现我应在何处投入时间和资源以获得最大的收益。
.
图3：投入自动化资源的最佳领域
点击放大
维护模式下的版本验证和回归测试——然后是外语G11N测试——很明显是首先应突破的领域。在产品仍在变化之中的时候试图自动化设计将是非常不切实际的，因为它将涉及大量自动化重复工作。
通过改变考虑中的标准和工具，你可以把这一技术应用于很多项目和初始版本。图4概括了这些步骤。
图4：一种区分自动化工具的引入的优先级顺序的技术的概括
|
|
一些软件开发工具的使用覆盖了整个开发周期，但是它们不能把顺序变成混乱。即使是最先进的工具也只能和它们支持的过程一样地工作。你的工具投资的回报将直接与你的过程成熟度级别成比例。级别越高，你可利用的特性就越多，你使用工具就越频繁，你使用的目的就越多。
如果你想要提高你的过程成熟度等级，引入自动化工具能够把你送上一个自然的进化过程达到这个目的。如果你正处在第一级并决定你要使用自动化工具，你必须首先写下你的测试步骤并使它们是可重复的；自动化工具本身则作为你由第一级升至第二级的催化剂。然后，在第二级，一旦你在一个组（比如测试）里建立了一个可重复的过程，你可以建立一个其它组可以采用的标准，这样你的自动化工具就成为了一个跨越测试，开发，需求工程，等等过程的共享基础设备。由于工具的使用你将可以进入更高的成熟度级别（第三级），而且工具将体现它的价值，因为更多人正在为更多目的使用它。你可以从那里开始使用工具来收集和跟踪每日工作进展和沟通数据，并实现到第四级的转变。最后，这一严格的数据收集将允许你精确地预报，计划，规划，和管理你的资源和项目，把你带到第五级。
我在这篇文章里提供的要点是容易实现的，并可以提高你任何工具实施的成功率。尽管如此，在最后，对你和你的团队是否确实已经准备好面对引入工具带来的挑战的决定权仍然在你。
我欢迎来自你们的反馈。如果你发现这些技术有所帮助请告诉我，并描述其它你的团队已经成功使用的技术。
附录A：检查过程的成熟度等级清单
|
附录B：测试过程的成熟度等级清单
|
附录C：在不同成熟度级别实现的IBM Rational工具
|
附录D：附加的CMM概况的笔记
所有改进努力的第一步都是相同的：一个现实的自我评估。CMM提供了研究会，指南，成熟度问卷，以及其他诊断手段来辅助这项评估。本文没有取代这些提供物；它只是向读者介绍CMM并提供跳跃地开始你的过程改进模型的要点。
为了恰当地评估你的组织，请单独看每一个开发阶段，并客观地调查不同级别上的不同从业者。
为了决定你的组织是否处于CMM第一级，判断你的软件和测试团队实践是否符合以下的任何一个描述：
- 为了获得灵活性，软件过程大体是在项目过程中由从业者和他们的管理者临时准备的。
- 即使确定了一个软件过程，它不是严格维护或强制从每个阶段或迭代中严格执行的。
- 团队的焦点是解决眼下的危机（救火）。
- 当强加了严峻的截止时间时，产品的功能和质量不得不对时间表做出妥协。
- 意图是加强质量的活动，比如结构化的评估和测试，在项目落后于时间表时经常被削减或取消。
如果来自项目管理团队高层和底层从业者的答案不同，不要感到惊讶。高层管理者可能会认为他们的组织是“高度成熟”的，因为他们相信满足外在的、可重复的数字和日期等同于过程按步骤进行。但实际上，为了满足数字和日期，工作雇员可能会放弃结构化代码回顾，不建立和记录可重复的单元测试，且不跟踪他们的设计变化。两个组的过程很可能无法集成以提供一个同步工作的环境。在这种情况下，我们需要对那些迭代使用低的成熟度级别并集中于标准的内容而不仅仅是数字。
这里有一个来自我自己的工作经历的尴尬例子。主要的目标是在一个具体日期前消除所有“未经核对的缺陷”。这些缺陷已经被找到，并提交以重新测试。我们知道，所有代码变化（比如，缺陷的修正）的10%将会造成其他问题，因此在一个特定日期前重新测试所有“未经核对的缺陷”使我们能够及时发现这些“预期”的错误并修改它们，提高产品的整体质量。要求的日期不断逼近，但是团队还落后于进程。为了赶时间，一些团队选择不经测试去除一些缺陷，留着潜在的10%的新错误。尽管这使得他们实现了标准的“文本”要求并使得他们的项目组件看起来稳定和符合目标，但实际上它破坏了质量目标的真实内容（发现那些新的错误）。
当团队感到压力，不得不以任何事为代价来“制造数字”时，那就是他们仍处于CMM第一级的信号。
739
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
