The flattening in the curve of bugs found will be interpreted in the most optimistic possible way unless you as test manager explain the limitations of the data:
平滑的错误曲线很容易以一种乐观的方式解释，除非你作为测试经理解释了数据的局限：
· "Only half the planned testing tasks have been finished, so little is known about half the areas in the project. There could soon be a big spike in the number of bugs found."
· 只有一半的计划测试做完了，对于项目的一半所知甚少。很快就有很多错误要被发现了。
· "That's especially likely because the last two weekly builds have been lightly tested. I told the testers to take their vacations now, before the project hits crunch mode."
· 很有可能这样，因为在过去的两个周构建只是略微测试了一下。我告诉测试员在项目进入艰难状态之前，现在开始休假。
· "Furthermore, based on previous projects with similar amounts and kinds of testing effort, it's reasonable to expect at least 45 priority-1 bugs remain undiscovered. Historically, that's pretty high for a successful product."
· 并且，根据以前的经验，可以预料到至少还有45个级别为1的 bug还没有发现。从历史看，这对于一个成功产品来说是很高的。
For discussions of using bug data, see [Cusumano95], [Rothman96], and [Marick97].
关于使用 bug 数据的讨论，请参阅[Cusumano95]、[Rothman96]和[Marick97]。
Earlier I asserted that testers can't directly improve quality; they can only measure it. That's true only if you find yourself starting testing too late. Tests designed before coding begins can improve quality. They inform the developer of the kinds of tests that will be run, including the special cases that will be checked. The developer can use that information while thinking about the design, during design inspections, and in his own developer testing.
我在前面说过，测试员不能直接提高质量，他们只能评估它。只有在你发现测试开始得太晚的时候，这种说法才是正确的。在编码开始前设计测试将会提高质量。他们让开发人员知道将进行什么样的测试，将检查哪些特殊用例。开发人员在思考设计、审查设计和自己做测试的时候可以使用这些信息。
Early test design can do more than prevent coding bugs. As will be discussed in the next theme, many tests will represent user tasks. The process of designing them can find user interface and usability problems before expensive rework is required. I've found problems like no user-visible place for error messages to go, pluggable modules that didn't fit together, two screens that had to be used together but could not be displayed simultaneously, and "obvious" functions that couldn't be performed. Test design fits nicely into any usability engineering effort ([Nielsen93]) as a way of finding specification bugs.
尽早测试的作用不仅仅是防止编码错误。像我们将在下一个主题中所讨论的那样，许多测试代表的是用户任务。设计它们的过程可以在昂贵的重新工作之前发现用户界面和可用性问题。我发现过的问题包括：错误消息不能显示在用户可以看到的地方，插件不能放到一起，两个必须同时使用的屏幕不能同时显示，一个“很明显”的功能不能执行。测试设计作为一个发现规格说明书 bug 的方法，很好地与可用性工程工作相适应([Nielsen93])。
I should note that involving testing early feels unnatural to many programmers and development managers. There may be feelings that you are intruding on their turf or not giving them the chance to make the mistakes that are an essential part of design. Take care, especially at first, not to increase their workload or slow them down. It may take one or two entire projects to establish your credibility and usefulness.
我应当说明早期介入测试对于许多程序员和开发经理来说不自然。可能有一种感觉是你干扰了他们，没有给他们在设计的基础部分犯错误的机会。小心些，尤其是在开始的时候，不要增加他们的工作量或减慢了他们的速度。可能需要一至两个完整的项目才能建立你们的可信度并显示出作用。
