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对应是非常困难的。她希望最初的请求能够附加在确认邮件的后面。并且，她意识到某些可户可能每天也会产生很多请求，所以会高度评价这个功能的。那么她将：
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
