Theme One: The Role of Testing
主題一：測試的作用
A first major mistake people make is thinking that the testing team is responsible for assuring quality. This role, often assigned to the first testing team in an organization, makes it the last defense, the barrier between the development team (accused of producing bad quality) and the customer (who must be protected from them). It's characterized by a testing team (often called the "Quality Assurance Group") that has formal authority to prevent shipment of the product. That in itself is a disheartening task: the testing team can't improve quality, only enforce a minimal level. Worse, that authority is usually more apparent than real. Discovering that, together with the perverse incentives of telling developers that quality is someone else's job, leads to testing teams and testers who are disillusioned, cynical, and view themselves as victims. We've learned from Deming and others that products are better and cheaper to produce when everyone, at every stage in development, is responsible for the quality of their work ([Deming86], [Ishikawa85]).
人們犯的第一個主要錯誤是認為測試小組應當負責質量保證。這個角色常常分配給組織中的第一測試小組，將它作為最后的防御，成為開發小組（被指責為產生低劣質量）和客戶（必須受到保護以遠離低劣質量）的一個屏障。它的特征是測試小組（常稱為“質量保證組”）表面上具有阻止產品發貨的權力。 這本身是一個令人沮喪的任務：測試小組不能提高質量，只能強制一個最低水平。更糟糕的是，這種權力常常是看上去比實際的重要。如果發現這一點，再加上有違常理地暗示開發人員質量是別人的事情，導致測試小組和測試員感到失望、憤事嫉俗、感覺自己是受害者。我們從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對應是非常困難的。她希望最初的請求能夠附加在確認郵件的后面。并且，她意識到某些可戶可能每天也會產生很多請求，所以會高度評價這個功能的。那么她將：
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
