Our Blog Excerpts Savings Contact

logo

Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > features
Features       Excerpts       Interviews

 

iDH Sign-Up


Get Our e-News
Delivered by FeedBurner

The Role of Testing

by James Bach

Adapted from Amplifying Your Effectiveness: Collected Essays. Reprinted by permission. All rights reserved. See below for copyright notice.
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.

AddThis Social Bookmark Button

 

 

 


COPYRIGHT NOTICE: This excerpt from Amplifying Your Effectiveness: Collected Essays [ISBN:0-932633-47-1] appears by permission of Dorset House Publishing. Copyright © 2000 by Gerald M. Weinberg. All rights reserved. See http://www.dorsethouse.com/books/aye.html. The material contained in this file may be shared for noncommercial purposes only, nonexclusively, provided that this Copyright Notice always appears with it. This material may not be combined with advertisements, online or in print, without explicit permission from Dorset House Publishing. For copies of the printed book or for permissions, contact Dorset House Publishing, 1-800-342-6657, 212-620-4053, http://www.dorsethouse.com, info@dorsethouse.com, New: 3143 Broadway, Suite 2B, New York, NY 10027 USA. Additional rights limitations apply, as presented in the Legal Disclaimer posted at http://www.dorsethouse.com/legal.html.

 

 

 
  DORSET HOUSE PUBLISHING CO., INC.
New:3143 Broadway, Suite 2B  New York, New York 10027  USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044
Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal