Classic mistakes cluster usefully into five groups, which I\'ve called \"themes\":
典型錯誤可以有效地分為五組，我把這些組稱為“主題”。
· The Role of Testing: who does the testing team serve, and how does it do that?
· 測試的作用：誰承擔測試小組的責任，如何做？
· Planning the Testing Effort: how should the whole team\'s work be organized?
· 制訂測試工作計劃：應該如何組織整個小組的工作？
· Personnel Issues: who should test?
· 人員問題：誰應該做測試？
· The Tester at Work: designing, writing, and maintaining individual tests.
· 工作中的測試員：設計、編寫和維護各測試。
· Technology Rampant: quick technological fixes for hard problems.
· 過度使用技術：艱難問題的快速技術修復
I have two goals for this paper. First, it should identify the mistakes, put them in context, describe why they\'re mistakes, and suggest alternatives. Because the context of one mistake is usually prior mistakes, the paper is written in a narrative style rather than as a list that can be read in any order. Second, the paper should be a handy checklist of mistakes. For that reason, the classic mistakes are printed in a larger bold font when they appear in the text, and they\'re also summarized at the end.
本文有兩個目標。第一，應當識別錯誤，將它們放到具體環境中，描述它們為什么是錯誤，并給出替代方法的建議。因為一個錯誤的具體環境通常是先決錯誤，所以本文將以敘事的方式而不是以可以按任意順序閱讀的列表方式來描述。第二，本文應該是一個便于查看的錯誤列表。因為這個原因，文章中出現的典型錯誤都以大號粗體字印刷，并在文章的結尾處匯總。
Although many of these mistakes apply to all types of software projects, my specific focus is the testing of commercial software products, not custom software or software that is safety critical or mission critical.
雖然這些錯誤很多都適用于所有類型的軟件項目，但我的重點將放在商用軟件產品的測試上，而不是定制軟件或者是高度安全或關鍵任務的軟件測試上。
This paper is essentially a series of bug reports for the testing process. You may think some of them are features, not bugs. You may disagree with the severities I assign. You may want more information to help in debugging, or want to volunteer information of your own. Any decent bug reporting system will treat the original bug report as the first part of a conversation. So should it be with this paper. Therefore, follow this link for an ongoing discussion of this topic.[Page]
本文主要是測試過程的一系列錯誤報告。你可能認為它們中的部分屬于特性問題而不是 bug。你可能不贊成我設定的嚴重性級別。你可能需要更多的信息以用于幫助排除錯誤，或者希望提供你自己的信息。任何設計良好的錯誤報告系統都將原始的錯誤報告當作是對話的起始部分。本文也是這樣，所以，可以按照鏈接參加這個主題的討論。
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.[Page]
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
