James Bach：测试人员的角色

以前，我是个开发人员。我不喜欢这个工作，无尽的压力让我疲惫。我几乎从未感觉到自己的工作做得足够好。我从未有过真正的休息。如果我没做好，我们就可能超过最后期限，或者是发布了一个垃圾产品。此后成为一个测试经理（test manager），感觉就像是休假一样。

测试同开发比起来，是一个非常模糊的工作——有很多的余地。我要做的仅仅是找问题。

我曾经认为测试的职责就是找问题。

找问题很简单，但是时间长了就会发现这样很难让人满意。我想让产品变得更好。

我曾是Apple一个400人团队中的众多测试专家之一。由于团队名称是软件质量保证（Software Quality Assurance），我们在质量保证（QA）上的讨论过比测试还多。一位经理推荐了一本书，Philip Crosby的《Quality Without Tears | 质量无泪 》，以此来帮助我们看到自己在产品开发过程中更深层次的职责。这本书提到了“零缺陷”，于是我转向了缺陷预防这一理念。“质量不是测出来的”是我们的口号。

 

我曾经认为测试的职责是保证质量。

但是，测试人员并不能真正的保证质量。首先，完美的质量本身就是不可及的目标。质量有多个方面，其中的一些就是冲突的。其次，测试人员并不创造质量，所以保证质量这样的职责并不在我们的能力范围之内。如果我们把自己想象成质量把关者，团队的其他人就有可能倾向于为质量少承担一些责任，他们会认为有QA在保证着质量——这样如果产品不是很好，我们就会承担主要责任。

除此之外，许多QA是通过定义流程和审查流程的执行来发挥作用。问题是，这样的一个方式很容易就会沦为关于质量的说教，在响亮的口号和常见的“好的质量是好的，不好的质量是不好的”式的争论中，QA所有的优点都看不见了。这就是为什么很多开发人员把QA视为耳边的噪音——只会另他们分心。

而我，从这种招人烦的角色中被解救了出来。经理把我叫到一边，告诉了我一个大秘密：一切都是为了风险——不必追寻完美，只需找到一个足够好的东西就够了。这样就把测试和质量保证转变成了一种项目的雷达，寻找敌人。我们在项目中是要快速的找到重要的问题，而不是每一个历史阶段中的每一个旧问题。

这深深的改变了我的思想。我不再像以前那么关注要在测试中达到尽可能全面的覆盖，而是关注哪一部分真正需要测试，并评估未知问题的风险。

考虑风险使测试人员在项目中更加容易与其他人相处。关于质量的讨论变成了判断哪些有影响，而不是纠结于谁想要完美。

我曾经认为测试的职责是分析风险。

风险是很重要，但它仍然是一种抽象的概念，而且悲观。一个开发经理跟我说他不喜欢谈论风险。“风险听起来很消极。我们不是保险公司理赔员，我们是企业家。我们勇于冒险。”他说的很在理。回报才是项目最重要的部分。难道对于测试，就找不到一个更全面和积极的观点了？

当然，测试的目的的确是发现问题、分析风险、以及保证质量，但是还有一种更本质的方式来看待我们的职责：我们照亮道路。没有测试，项目在黑暗中乱撞、被障碍绊倒、最后跌下悬崖。而测试会在需要的地方点亮火把，来帮助开发人员和经理知道他们在哪、他们要去哪、还有他们什么时候能到达。

现在，我认为测试的职责是提供重要信息，来协助创造和运营优秀的产品。这包括了发现问题、保证质量、分析风险、以及其他任何能够帮助团队了解当前状况的方式。

*********

原文：

The Role of Testing 

by James Bach

Once upon a time, I was a developer. I didn't like it. Day in and day out, the pressure wore me down. I rarely felt that my work was good enough. I never felt free to take time off. If I messed up, we would blow a deadline or ship a doggy product. After that experience, being a test manager seemed like a vacation.

Testing is such a vague activity compared to programming—there's lots of wiggle room. All they wanted me to do was find problems.

I used to think that 
the role of testing is to find problems.

Finding problems was easy, but not very satisfying in the long run. I wanted to help the product be really good.

I was one of many test specialists in a group of about 400 at Apple. Since our group was called Software Quality Assurance, there was earnest talk about how quality assurance (QA) was more than just testing. One of the other managers circulated a book called Quality Without Tears, by Philip Crosby, as a way to help us see our deeper role in product development. The book spoke of "zero defects," and I became a convert to the philosophy of bug prevention. "You can't test quality into the product" was our mantra.

I used to think that 
the role of testing is to assure quality.

Testers can't really assure quality, though. For one thing, perfect quality is an inherently unreachable goal. There are many dimensions to it, and some of them conflict. For another thing, testers don't create quality, so such a role is not really in our power to perform. Even if we think of ourselves only as quality gatekeepers, the rest of the team will tend to take a little less responsibility for quality; they'll figure QA is there to "assure" it—and to receive the brunt of blame if the product isn't good enough.

Besides, the natural instinct of many QA people is to exert control by defining processes and auditing process compliance. The problem is that such an approach slips so easily into moralizing about quality, wherein all of the trade-offs and subtleties of excellence are lost in the glare of slogans and general arguments that good quality is good and bad quality is bad. That's why it's so common for developers to perceive QA as just an annoying buzz in their ears—just another distraction, not a contribution.

In my case, I was rescued from life as a horsefly. My manager took me aside and told me a great secret: It's all about risk—not the search for perfection, but the search for something good enough. That transforms testing and quality assurance into a form of project radar, scanning for the enemy. We are in the project to find important problems fast, not just any old problem at any old pace.

This changed my thinking profoundly. I no longer focused so much on covering the product as completely as I could in my tests, but rather on understanding what parts of the product really needed to be tested and on judging the risk of unknown problems based on known problems.

Thinking about risk brings testers more into alignment with everyone else on the project. Conversations about quality become an examination of what matters, rather than a struggle over who cares about excellence and who doesn't.

I used to think that 
the role of testing is to analyze risk.

Risk is important, but it's also kind of an abstract concept, and a downbeat one, at that. One development manager told me he didn't like talking about risk. "It sounds so negative. Hey, we aren't insurance actuaries, we're entrepreneurs. We take risks." He had a point. Reward is really the whole point of the project, right? Can't we find a more expansive and positive view of testing?

Certainly the point of testing is to help find problems, analyze risk, and assure quality, but there is a more essential way of looking at our role: We light the way. Without testing, projects blunder along in the dark, tripping over obstacles and falling over cliffs. The testing process focuses light where it's needed to help developers and management know where they are, where they ought to go, and when they have arrived.

Today, I think the role of testing is to bring vital information to light in support of the grand mission of creating great products and running the business. That includes finding problems, assessing quality, analyzing risk, and in any other way helping the team to understand what's going on.

I wonder what I'll think testing is tomorrow.