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

　　人們犯的第一個主要錯誤是認為測試小組應當負責質量保證。這個角色常常分配給組織中的第一測試小組，將它作為最后的防御，成為開發小組(被指責為產生低劣質量)和客戶(必須受到保護以遠離低劣質量)的一個屏障。它的特征是測試小組(常稱為“質量保證組”)表面上具有阻止產品發貨的權力。 這本身是一個令人沮喪的任務：測試小組不能提高質量，只能強制一個最低水平。更糟糕的是，這種權力常常是看上去比實際的重要。如果發現這一點，再加上有違常理地暗示開發人員質量是別人的事情，導致測試小組和測試員感到失望、憤事嫉俗、感覺自己是受害者。我們從Deming 和其他人的工作可以得知：如果每個人都在開發的各個階段對他們的工作質量負責，則產品會又好又便宜([Deming86]，[Ishikawa85])。

　　In practice, whatever the formal role, most organizations believe that the purpose of testing is to find bugs. This is a less pernicious definition than the previous one, but it's missing a key word. When I talk to programmers and development managers about testers, one key sentence keeps coming up: "Testers aren't finding the important bugs." Sometimes that's just griping, sometimes it's because the programmers have a skewed sense of what's important, but I regret to say that all too often it's valid criticism. Too many bug reports from testers are minor or irrelevant, and too many important bugs are missed.

　　實際上，不管表面上的作用是什么，大多數組織都相信測試的目的是發現 bug。這個定義的危害比前一個定義的危害要小，但是忽略了一個關鍵詞。當我同程序員和開發經理談到測試員的時候，不時聽到一個關鍵的句子：測試員找不到重要的 bug。有時候這種說法只是一種抱怨，有時候是因為程序員對于什么是正確的感覺不對，但我很遺憾地說，它們經常是有效的批評。測試員的太多的bug 報告是微小的、不相關的，而有太多重要的錯誤都被遺漏了。

　　What's an important bug? Important to whom? To a first approximation, the answer must be "to customers". Almost everyone will nod their head upon hearing this definition, but do they mean it? Here's a test of your organization's maturity. Suppose your product is a system that accepts email requests for service. As soon as a request is received, it sends a reply that says "your request of 5/12/97 was accepted and its reference ID is NIC-051297-3". A tester who sends in many requests per day finds she has difficulty keeping track of which request goes with which ID. She wishes that the original request were appended to the acknowledgement. Furthermore, she realizes that some customers will also generate many requests per day, so would also appreciate this feature. Would she:

　　什么是重要的 bug?對誰而言是重要的?直觀的估計，答案肯定是“對于客戶”。聽到這個定義，幾乎每個人都會點頭稱是，但他們確實這樣認為嗎?這里要測試一下你們組織的成熟度。假設你們的產品是一個接受電子郵件請求服務的系統。當收到請求時，它馬上發送一個“您在97年5月12日發送的請求已經受理，參考ID是 NIC-051297-3”的答復。一個每天發送很多請求的測試員發現要分清楚哪個請求與哪個ID對應是非常困難的。她希望最初的請求能夠附加在確認郵件的后面。并且，她意識到某些可戶可能每天也會產生很多請求，所以會高度評價這個功能的。那么她將：

　　1. file a bug report documenting a usability problem, with the expectation that it will be assigned a reasonably high priority (because the fix is clearly useful to everyone, important to some users, and easy to do)?

　　寫一個 bug 報告，記錄一個可用性問題，希望能夠分配一個合理的高優先級(因為這個修復很明顯對每個人都很用，對有部分用戶來說還非常重要，并且也容易修改)?

　　2. file a bug report with the expectation that it will be assigned "enhancement request" priority and disappear forever into the bug database?

　　寫一個 bug 報告，希望它被分配為“功能提升請求”優先級并永遠從 bug 數據庫中消失?

　　3. file a bug report that yields a "works as designed" resolution code, perhaps with an email "nastygram" from a programmer or the development manager?

　　寫一個 bug 報告，產生一個“按設計工作”解決碼，可能還加上一個來自程序員或開發經理的“不同意”電子郵件?

　　4. not bother with a bug report because it would end up in cases (2) or (3)?

　　不打算費事去寫 bug 報告，因為它將以情況(2)或(3)結束?

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