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

　　If usability problems are not considered valid bugs, your project defines the testing task too narrowly. Testers are restricted to checking whether the product does what was intended, not whether what was intended is useful. Customers do not care about the distinction, and testers shouldn't either.

　　如果可用性问题不认为是有效的 bug，那么你们的项目将测试任务定义得太狭窄了。测试员严格限制为检查产品是否按预期工作，而不管这种预期是否有效。客户不关心这个区别，测试员也不应该关心。

　　Testers are often the only people in the organization who use the system as heavily as an expert. They notice usability problems that experts will see. (Formal usability testing almost invariably concentrates on novice users.) Expert customers often don't report usability problems, because they've been trained to know it's not worth their time. Instead, they wait (in vain, perhaps) for a more usable product and switch to it. Testers can prevent that lost revenue.

　　测试员经常是组织中唯一像专家一样大量使用系统的人。他们会注意到专家会看到的可用性问题。(形式上的可用性测试几乎不可避免地集中于没有经验的用户。)专家客户常常不会报告可用性问题，因为他们已经被训练的知道不值得花时间去这样做。相反，他们(也许是徒劳地)等待下一个可用的产品然后切换过去。测试员可以避免这个损失。

　　While defining the purpose of testing as "finding bugs important to customers" is a step forward, it's more restrictive than I like. It means that there is no focus on an estimate of quality (and on the quality of that estimate). Consider these two situations for a product with five subsystems.

　　将测试的目的定义为“找到对用户重要的 bug ”是向前进了一步，但与我所喜欢定义相比仍有限制。这意味着没有集中于质量评估(以及这种评估的质量)。考虑一下测试含有五个子系统的产品的两种情况。

　　1. 100 bugs are found in subsystem 1 before release. (For simplicity, assume that all bugs are of the highest priority.) No bugs are found in the other subsystems. After release, no bugs are reported in subsystem 1, but 12 bugs are found in each of the other subsystems.

　　在发布前，在子系统1中找到了100个bug 。(为了简单起见，假设所有的 bug 都是最高级别的。)在其他子系统中没有发现 bug 。在发布后，在子系统1中没有报告 bug ，但在其他每个子系统中都报告了12个 bug 。

　　2. Before release, 50 bugs are found in subsystem 1. 6 bugs are found in each of the other subsystems. After release, 50 bugs are found in subsystem 1 and 6 bugs in each of the other subsystems.

　　在发布前，在子系统1中找到了50个 bug 。在其他每个子系统中都找到了6个 bug 。在发布后，在子系统1中报告了50个 bug ，在其他每个子系统中都报告了6个 bug。

　　From the "find important bugs" standpoint, the first testing effort was superior. It found 100 bugs before release, whereas the second found only 74. But I think you can make a strong case that the second effort is more useful in practical terms. Let me restate the two situations in terms of what a test manager might say before release:

　　从“找到重要 bug”的观点看，第1种测试情况较为理想。在发布前找到了100个 bug ，但是第2种情况中只找到74个。但我想你们可能会提出一个有力的理由认为第2中测试在实际中更有用。让我以产品发版前测试经理可能说些什么来重新描述一下两种测试情况：

　　1. "We have tested subsystem 1 very thoroughly, and we believe we've found almost all of the priority 1 bugs. Unfortunately, we don't know anything about the bugginess of the remaining five subsystems."

　　“我们全面测试了子系统1，我们相信已经找出了几乎所有优先级为1的 bug。不幸的是，我们对其他五个子系统的的 bug 一无所知。”

　　2. "We've tested all subsystems moderately thoroughly. Subsystem 1 is still very buggy. The other subsystems are about 1/10th as buggy, though we're sure bugs remain."

　　“我们比较全面地测试了所有的子系统。子系统1仍旧有不少 bug。其他子系统虽然还有 bug，但只有子系统1的 bug 的十分之一。”

　　This is, admittedly, an extreme example, but it demonstrates an important point. The project manager has a tough decision: would it be better to hold on to the product for more work, or should it be shipped now? Many factors - all rough estimates of possible futures - have to be weighed: Will a competitor beat us to release and tie up the market? Will dropping an unfinished feature to make it into a particular magazine's special "Java Development Environments" issue cause us to suffer in the review? Will critical customer X be more annoyed by a schedule slip or by a shaky product? Will the product be buggy enough that profits will be eaten up by support costs or, worse, a recall?

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