（转载）将有效的软件QA提升到下一个层次

Jerry推荐[2006-4-27]
出处：网络
作者：Len DiMaggio

本文来自于 Rational Edge：当软件开发团队到达了精通的级别，要想找到提高的方法会非常困难。从质量保证经理的角度看，本文提供实用的建议，几乎在开发生命周期的每个区域工作的团队都可能将建议应用到他们的工作中。

一段时间以前，我和一个朋友，一家小型软件公司中的重要人物，讨论有关软件测试的内容。他热心于其质量保证（quality assurance，QA）团队所做的工作，然而尽管他们做了工作，包括创建大量的自动化测试，但他仍旧担心要对公司的产品进行充分测试所花费的时间。“我们需要让 QA 团队更加高效，”他说。“他们做的很好，但我需要让他们达到更高一层。”

他对提高 QA 团队的效率所表现的悲伤令我想起了...高尔夫。（等我一会。）高尔夫是很难学的运动。但真正困难的是，您做得越好，就越难以提高。在 100 米到 90 米间很难得分。在 80 米内得分较难，而在 70 米内得分甚至更难。一旦您到达了那个水平，就要进行很多工作来维持。我可以从自己的经历说起。在结婚 ＋ 抵押贷款 ＋ 生小孩之前，我在又长又有困难的高尔夫球道上遇到 6 或 7 个障碍。现在我在较短而不那么困难的球道上遇到 9 到 10 个障碍。为什么？一个原因是我一年中打高尔夫的次数与过去一周的一样。我希望不久将解决此情况 —— 我只是为孩子（三岁和五岁）买了他们自己的球棒。

这对软件测试也一样。QA 团队通过将包含测试计划、缺陷原因分析，和自动化测试的正式、可重复的过程，替代特殊的测试方法，以变得更加有效且高效。这些操作并不简单，但现今它们对软件 QA 团队来说是相当标准的。但当您做完了所有那些操作，您还能如何继续提高到“下一个层次”？

那天我没有回答他。但从那以后就开始考虑，我认为答案依赖于本文中所描述的操作。

了解您的目标：您所说的“高效”是什么意思？

每当我开始一项工作时，第一步是确保我在讨论提高 QA 团队的效率的时候了解最终的目标。我们必须清楚地定义我们所说的“效率”。标准的（出自于dictionary.com）高效定义是：

ef·fi·cient, adj.

直接产生效果：生效的原因。参见“高效”的同义词。

a. 用最少的浪费、开销或不必要的工作来有效地生产。

b. 展示高比率的输出到输入。

让我们退回一步，定义对于软件 QA 团队来说什么是高效。为了这样做，我们还需要回退一步，并且提醒我们自己，软件 QA 团队和软件测试通常的主要目标。

软件 QA 团队有许多责任。团队不得不审阅功能规格并对作者提供评论。团队必须建立测试工具并撰写测试计划。团队必须运行测试并报告测试结果。还有许多。但所有这些活动都只是意味着一个结束。这个结束就是要寻找缺陷（bug），尤其是那些还没有找到并可能影响到您的客户的缺陷。这就是为什么我们要测试软件的原因：找到缺陷。所有的研究、计划、审阅、测试自动化开发，和维护都为了一个目的：使我们找到软件中的缺陷。因此，当我们讨论软件 QA 团队的效率时，我们真正的意思是我们希望团队能很快找出更严重的缺陷。

现在，我的朋友（我在引言中提到的软件重要人物）所谈论的效率是希望他的 QA 团队能够在，比方说四天内检验一个产品，而不是八天。实质上，此目标意味着 QA 团队必须更快地找出严重缺陷。为了专注于更快找出那些严重缺陷，团队成员不得不停止浪费在妨碍寻找缺陷的工作上所花费的时间。

所以，让高效的团队更加高效的第一步是仔细观察您目前不高效的地方。换句话说，您正在做的，而没有辅助您寻找严重缺陷的事情是什么。什么引导我们进入下一个操作。

“我们决不要欺骗自己”：了解您的团队的低效。

John D. Rockefeller 有一句伟大的格言：“我们决不要欺骗自己。”也许这是他为什么这样成功的原因：他总是对自己诚实。

如果您打算了解现在您的 QA 团队哪里效率低，那么您将必须重视使团队有效的实践。最可能的是，那些实践是现实世界经验的结果，以及其他知名实践的调整，加上许多艰苦的工作。您必须准备改变，并且甚至放弃这些实践中的一些。

这些实践也许很难完成。毕竟，这些实践是对团队有效的主要贡献因素。人们可能对它们有严重的情感依恋。但如果您想要将团队提升到“下一个高效层次”，那么您必须愿意将团队如何工作的所有方面都改变。

问题是：在团队实践分析中，您遵照的是什么？记住，您想要鉴别的正在执行的任务是不会导致新的、严重缺陷的发现，以及那些根据用在他们生成的缺陷上的时间和工作来说只是太昂贵的任务。基本上，您必须将您的计划、希望，和想像与实际比较。软件 QA 团队花时间进行调查研究、测试设计、编码、分解、调试、执行和分析。在项目的开始阶段，团队可能编制出一个完成任务所需的估算时间和人力资源的进度安排。然后，随着整体的项目目标的改变，那个进度安排被丢弃并且决不再看。您必须要做的是实际追踪您要完成任务所花费的时间或努力，和真正发生的事情之间的差异。您必须将此时间或工作的分析交叉引用到工作所产生的结果上（也就是，缺陷）。

所以，在一个项目过程中，有效的 QA 团队可能会在哪里损失时间？（您能对此做些什么？）我所看到的一个部分是负担累赘。

负担累赘

如果您的 QA 团队已经在一起一段时间了，并且如果在测试中已经很有效，那么必须建立相当多的自动化测试和运行测试的框架。但是可能有许多测试的生命长过其有效时期。随着越来越多的测试被撰写出来，团队可能必须拿出不断增加的时间量来维护测试及其框架。

我最近见到一个在一家非常成功的软件公司工作的人，该公司中的 QA 团队就有这样的问题。经过十多年的工作，他们已经创建了差不多数千个自动测试。实际上，他们有许多测试，要运行所有的测试几乎要花上一整天。在这些年内，如此多的人写了那么多的测试，没有人清楚所有这些测试所测的是什么。

这是测试自动化的负担。在那些时候，每个测试都是出于很好的理由而撰写的。但是随着时间的过去，每个测试的理论根据已经失去了。而且，将这些测试组织为多种、但仍旧非常大的测试组。结果是，甚至是单个的测试组都要花几个小时来运行。团队总是为产品中新的或修改了的特性撰写新的测试。要更加高效，他们需要“减少不再提供价值的测试组”。

您如何使测试更加高效？少测试。跳过那些不能充分证明还有效果的测试。集中于撰写和运行更重要的测试。换句话说，撰写并运行那些将找到新的更严重的缺陷的测试。

OK。这听起来很容易。但是您如何确定哪个测试是足够重要的，以至于对它们运行并维护？这全部依赖于您的产品中最危险的部分。换句话说，现今谁最危险。

了解产品的风险以及总是调整风险变更的需要。

有时候，因为是新增的或者因为遭受了变更，代码处于危险之中。Myers（在 Art of Software Testing —— 仍旧是我所看到的最好的软件测试书籍），1 谈论了一般在已经改正了老的缺陷的区域上如何找到新的缺陷。这可能因许多原因而出现 —— 也许因为代码是多缺陷的，设计是不完善的，或者因为它经常变更，并且问题常常出现在原始代码没什么问题的时候，而是因为正在增加新的特性。

随着新特性变老，这种级别的风险会随着时间而变更。如果代码没有随着时间而变更，不论是由于缺陷或是增强，与其他代码相关的风险级别可能降低。因此总是知道当前的情况并调整计划，处理处于风险中的部分是很重要的。您的资源总是有限的，但是可能的测试数量总是无限的。

有时候，风险级别与代码的“健康”无关，但是因为正在讨论的特性（或配置）一般对产品或具体的客户来说是关键的。我曾经在一家网络公司工作过，该公司将一个产品进行了 beta 测试，尽管用某一种类型的调制解调器会失败。发生了什么？您猜猜，第一个测试版的用户就使用了那个类型的调制解调器。

除了了解处于风险中的部分以外，您还必须不断调整您的计划以匹配软件变化的状态。作为媒介的软件是有延展性的，2 以至于很容易快速进行根本的变更，并且与此同时很快引入新的风险。您试图提前预料每一件事，但是在测试期间，您总是了解到一些新的内容，并且不得不改变计划，结合新的或变更的（或删除的）测试。

总结

使得效率低的团队高效起来是很难的。

如果您想确定您的团队在哪里，如何效率低，那么不要欺骗自己。对时间花费在哪里，及如何花费的进行关键性的审阅。接受您某天就将不得不把一些测试抛弃的事实。

对于 QA 团队来说什么是高效的？既是他们能快速地找到严重的缺陷。

为了更高效，并找出那些严重的缺陷，着重于处于危险中的内容。

记住处于危险中的事物总是变化的，您不得不适应且保持适应。

注释

1 Glenford J. Myers、Corey Sandler、Tom Badgett 和 Todd M. Thomas， Art of Software Testing，第二版。John Wiley & Sons，2004 年。

2 Frederick P. Brooks，Jr.，“没有银弹：软件工程的本质和事故。”http://portal.acm.org/citation.cfm?id=26440.26441&dl=GUIDE&dl=GUIDE&CFID=66886534&CFTOKEN=1562060

参考资料

您可以参阅本文在 developerWorks 全球站点上的 英文原文。

关于作者

<shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"><font size="1"><stroke joinstyle="miter"></stroke><formulas><f eqn="if lineDrawn pixelLineWidth 0"></f><f eqn="sum @0 1 0"></f><f eqn="sum 0 0 @1"></f><f eqn="prod @2 1 2"></f><f eqn="prod @3 21600 pixelWidth"></f><f eqn="prod @3 21600 pixelHeight"></f><f eqn="sum @0 0 1"></f><f eqn="prod @6 1 2"></f><f eqn="prod @7 21600 pixelWidth"></f><f eqn="sum @8 21600 0"></f><f eqn="prod @7 21600 pixelHeight"></f><f eqn="sum @10 21600 0"></f></formulas><path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"></path><lock v:ext="edit" aspectratio="t"></lock></font></shapetype><shape id="_x0000_s1026" style="MARGIN-TOP: 527.3pt; Z-INDEX: 1; LEFT: 0px; MARGIN-LEFT: 0px; WIDTH: 48pt; POSITION: absolute; HEIGHT: 57pt; TEXT-ALIGN: left; mso-position-horizontal: left; mso-position-horizontal-relative: text; mso-position-vertical-relative: line; mso-wrap-distance-left: 1.5pt; mso-wrap-distance-top: 1.5pt; mso-wrap-distance-right: 1.5pt; mso-wrap-distance-bottom: 1.5pt" o:allowoverlap="f" alt="作者照片" type="#_x0000_t75"><imagedata o:title="dimaggio" src="file:///C:%5CDOCUME~1%5Cxgu%5CLOCALS~1%5CTemp%5Cmsohtml1%5C01%5Cclip_image001.jpg"></imagedata><wrap type="square"></wrap></shape>Len DiMaggio 是 IBM Rational 的软件质量工程师和经理。在加入 Rational 之前，在 BBN、CTE 和 Genuity 领导软件测试团队。Len 已经在 STQE、Software Development、Dr. Dobbs Journal，和 QAI Journal 上发表过关于软件测试的文章。

<!--Here is the bottom-->