典型的測試錯誤有哪些？(4)

　　必須承認，這是一個極端的例子，但是證明了一個重要的觀點。項目經理有一個艱難的決定：是延遲產品交付，再工作一段時間，還是現在就交付使用?許多因素 ——都是一些大致的評估——都必須予以權衡：競爭對手會搶先發布產品并占領市場嗎?如果丟掉一個未完工的功能部件會使得某一個雜志的 “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數據誤導。沒有具體環境，項目管理傾向于集中于一幅圖：

　　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.

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