| 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. | 
