在發布前，在子系統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?
必須承認，這是一個極端的例子，但是證明了一個重要的觀點。項目經理有一個艱難的決定：是延遲產品交付，再工作一段時間，還是現在就交付使用？許多因素——都是一些大致的評估——都必須予以權衡：競爭對手會搶先發布產品并占領市場嗎？如果丟掉一個未完工的功能部件會使得某一個雜志的 “Java 開發環境” 特別期刊的評論中對我們造成損害嗎？關鍵客戶 X 對產品延期和劣質產品哪一個更感到煩惱？產品是否有很多 bug，以至于支持成本會吃掉利潤，或者更糟糕的是將產品召回？
The testing team will serve the project manager better if it concentrates first on providing estimates of product bugginess (reducing uncertainty), then on finding more of the bugs that are estimated to be there. That affects test planning, the topic of the next theme.
如果測試小組首先集中于產品錯誤的估計（減少不確定性），然后再找到更多的錯誤，他們會更好地服務于項目經理。這會影響測試計劃。測試計劃將在下個主題中論述。
It also affects status reporting. Test managers often err by reporting bug data without putting it into context. Without context, project management tends to focus on one graph:
這也會影響狀態報告。測試經理常常會被沒有放到具體環境中的報告 bug數據誤導。沒有具體環境，項目管理傾向于集中于一幅圖：
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
