标题:Counting what really counts
原作者:Harry Robinson 2001/6/21(test productivity program manager for Six Sigma)
翻译:liulichuan.cn
场景1 你正在河边野炊。你注意到一个人不幸掉入河中。你跳到水里把这个人救上来。市长过来给你颁发一枚奖章。你继续野炊。
几分钟后,你发现又一个人在水里挣扎。你再次营救,因此获得第二枚奖章。
几分钟后,第三个人,第三次营救,第三枚奖章。。。如此持续了一天。
黄昏的时候,你被奖章和荣誉压得直不起腰。你是一个英雄。当然,你大脑的某个地方会偷偷地琢磨——你应当去河的上游,看看为什么整天都不断有人落入水里。但是,这不会让你得到那么多的奖章。
场景2 你正坐在电脑前。你发现一个Bug。你的经理过来给你一个“Bug 发现者”的奖励。几分钟后,你发现第二个Bug。诸如此类。
这天结束的时候,你拥有许多的“Bug 发现者”的奖励和股票期权。你是一个英雄。或许你应当协助阻止这些Bug进入系统,如果你的大脑蹦出这个想法,你会压扁它。因为阻止Bug不能为你赢得发现Bug那么多的奖励。
你所权衡的是你所得到的
B.F. Skinne 50年前告诉我们:老鼠和人都倾向执行那些他们可以获得奖励的行为。今天这句话仍然是正确的。现如今,只要测试人员发现有针对他们的评估指标,他们都非常努力地提升和这个指标相关的能力,甚至他们的行为并不真正对项目有用。如果你的测试人员发现你重视发现Bug,最终结果将是一个“Bug发现者”的团队。如果协助阻止Bug没有受到重视,防范Bug将不会被实行。
举个例子,我曾经在一个公司工作,那里测试人员仅仅因为他们发现的bug数量受到奖励,而不是因为给客户发布好的产品。结果,如果测试人员在需求文档里面发现可能的问题,他们不会给开发团队指出来。他们会先把问题搁置直到代码提交测试后再疯狂测试,提交非常多的Bug。测试人员因为发现大量的Bug受到奖励,但是整个项目因为滞后的代码变动和bug修复深受其害。
这个例子听起来很疯狂,但却是事实,因为Bug数量的度量指标支持这种可能。
另一方面,我知道一个类似的项目,那里测试人员为发布一个高质量的产品而工作。他们参与需求评审并指出问题;他们进行代码评审协助阻止缺陷;他们和开发工作紧密。结果呢,正式提交测试的代码只发现很少的bug,而一个高质量的软件发布给客户。
很不幸,管理人员在测试阶段把注意力集中在bug数量指标上。如果在正式提交测试阶段,测试人员发现很少的bug,管理人员会认为开发人员干得不错并且给他们一笔奖金。测试团队却没有得到奖金。你认为会有多少测试人员在下一个项目阻止Bug的产生吗?
和Bug无关
软件测试不是去发现bug,而是发布伟大的软件。没有客户会说:“天哪!你们发现和修复了65000个bug,这一定是一个伟大的软件!”
所以,为什么我们还在使用Bug数量作为一个衡量工具呢?答案很简单:Bug很容易计算以至于几乎无法抗拒。它们可以被计数,跟踪,用于预测。和它们的数字游戏是很吸引人的,例如用KLOC(千行代码)除以Bug,基于时间绘制曲线,或者预测他们未来的几率。
但是,所以这些都忽略了bug数量下面的复杂性。就好比听说亚利桑那以3:2赢得世界锦标赛的决赛。这些数字丝毫不能告诉我们是如何赢得或失去锦标赛的。Bug是流程的一个有用的晴雨表,但是它们不能说明所有的事情,它们仅能帮助你问一些有用的问题。
那么我们应当权衡什么?
这是一些想法:
“项目所需工时”是我们真正关心的真实成本。你的整个团队(产品经理,开发人员,测试人员)如何有效地从发布产品的角度出发?不要把这些组看成独立的团队,互相之间有明确的工作交付,而应该把他们看作一个从概念到代码实现的整体。鼓励不同工种在一起工作:产品经理创建更加清晰的需求文档,开发人提供可测试的代码,测试人员提供早期反馈并测试。
你的客户发现多少bug?你的客户如何谈论你的产品?你将所有售后支持部门的电话记录都看过吗?
你阻止了多少bug?有没有用一些工具在最终编译之前清理代码?有没有跟踪结果?
需求和代码的测试范围是否有效?覆盖范围可以是一个有用的(尽管不是全面的)关于测试如何进行的指标。
最后,一个有启迪作用的指标:你的下属有多少人对产品的质量充满自信?在一些飞机制造公司,工程师在项目签字表示任务完成之后,他们都要坐上飞机进行一次快速的测试飞行。
假设你的工程师伙伴们没人愿意去死,这个指标你必须去尊重!不要只提你发现了很多的bug,而要说你对可发布的结果非常满意。
我最近看了一个邮件签名:We are what we measure. It’s time we measure what we want to be.