标题：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.
542
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
