典型的测试错误有哪些？(2)

　　人们犯的第一个主要错误是认为测试小组应当负责质量保证。这个角色常常分配给组织中的第一测试小组，将它作为最后的防御，成为开发小组(被指责为产生低劣质量)和客户(必须受到保护以远离低劣质量)的一个屏障。它的特征是测试小组(常称为“质量保证组”)表面上具有阻止产品发货的权力。 这本身是一个令人沮丧的任务：测试小组不能提高质量，只能强制一个最低水平。更糟糕的是，这种权力常常是看上去比实际的重要。如果发现这一点，再加上有违常理地暗示开发人员质量是别人的事情，导致测试小组和测试员感到失望、愤事嫉俗、感觉自己是受害者。我们从Deming 和其他人的工作可以得知：如果每个人都在开发的各个阶段对他们的工作质量负责，则产品会又好又便宜([Deming86]，[Ishikawa85])。

　　In practice, whatever the formal role, most organizations believe that the purpose of testing is to find bugs. This is a less pernicious definition than the previous one, but it's missing a key word. When I talk to programmers and development managers about testers, one key sentence keeps coming up: "Testers aren't finding the important bugs." Sometimes that's just griping, sometimes it's because the programmers have a skewed sense of what's important, but I regret to say that all too often it's valid criticism. Too many bug reports from testers are minor or irrelevant, and too many important bugs are missed.

　　实际上，不管表面上的作用是什么，大多数组织都相信测试的目的是发现 bug。这个定义的危害比前一个定义的危害要小，但是忽略了一个关键词。当我同程序员和开发经理谈到测试员的时候，不时听到一个关键的句子：测试员找不到重要的 bug。有时候这种说法只是一种抱怨，有时候是因为程序员对于什么是正确的感觉不对，但我很遗憾地说，它们经常是有效的批评。测试员的太多的bug 报告是微小的、不相关的，而有太多重要的错误都被遗漏了。

　　What's an important bug? Important to whom? To a first approximation, the answer must be "to customers". Almost everyone will nod their head upon hearing this definition, but do they mean it? Here's a test of your organization's maturity. Suppose your product is a system that accepts email requests for service. As soon as a request is received, it sends a reply that says "your request of 5/12/97 was accepted and its reference ID is NIC-051297-3". A tester who sends in many requests per day finds she has difficulty keeping track of which request goes with which ID. She wishes that the original request were appended to the acknowledgement. Furthermore, she realizes that some customers will also generate many requests per day, so would also appreciate this feature. Would she:

　　什么是重要的 bug?对谁而言是重要的?直观的估计，答案肯定是“对于客户”。听到这个定义，几乎每个人都会点头称是，但他们确实这样认为吗?这里要测试一下你们组织的成熟度。假设你们的产品是一个接受电子邮件请求服务的系统。当收到请求时，它马上发送一个“您在97年5月12日发送的请求已经受理，参考ID是 NIC-051297-3”的答复。一个每天发送很多请求的测试员发现要分清楚哪个请求与哪个ID对应是非常困难的。她希望最初的请求能够附加在确认邮件的后面。并且，她意识到某些可户可能每天也会产生很多请求，所以会高度评价这个功能的。那么她将：

　　1. file a bug report documenting a usability problem, with the expectation that it will be assigned a reasonably high priority (because the fix is clearly useful to everyone, important to some users, and easy to do)?

　　写一个 bug 报告，记录一个可用性问题，希望能够分配一个合理的高优先级(因为这个修复很明显对每个人都很用，对有部分用户来说还非常重要，并且也容易修改)?

　　2. file a bug report with the expectation that it will be assigned "enhancement request" priority and disappear forever into the bug database?

　　写一个 bug 报告，希望它被分配为“功能提升请求”优先级并永远从 bug 数据库中消失?

　　3. file a bug report that yields a "works as designed" resolution code, perhaps with an email "nastygram" from a programmer or the development manager?

　　写一个 bug 报告，产生一个“按设计工作”解决码，可能还加上一个来自程序员或开发经理的“不同意”电子邮件?

　　4. not bother with a bug report because it would end up in cases (2) or (3)?

　　不打算费事去写 bug 报告，因为它将以情况(2)或(3)结束?

原文转自：http://www.uml.org.cn/Test/200709289.asp