典型的測試錯誤有哪些？(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，那么你們的項目將測試任務定義得太狹窄了。測試員嚴格限制為檢查產品是否按預期工作，而不管這種預期是否有效?？蛻舨魂P心這個區別，測試員也不應該關心。

　　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