James Bach on Explaining Testing to Them

Don't you love it when a programmer or manager makes ignorant statements about testing? You don't? Well, I do. At least they're talking. My experience is that most of my non-tester colleagues, no matter how smart and talented they are in their own work, are pretty mixed-up about my line of work. But if they don't say anything, there's not a lot I can do about it. So, in a way, I feel better when I hear one of them say something like "You play with each feature and see if it works, right? What's the big deal?"

Because if they talk, maybe they'll listen. If they listen, maybe I can offer them a more useful view of testing.

Maybe you think your co-workers should already understand how testing works. I feel your pain. Now, get over it. You are the testing specialist. You like this stuff. Because you're good at it, the other project roles can focus better on what they do well. Take their confusion as evidence that you are needed.

In testing, it's us versus them. Well, not really, but you may feel that way sometimes. Good explanations help bring the team together. This is important, because the rest of the project team, including managers all the way up the chain, won't fully support your work unless they understand what you're trying to do.

It Starts with Intent and Attitude
I suggest that you approach every explaining situation with the same intent: to make your clients or co-workers more powerful and successful, to help them make more effective decisions, and to help them know how to get the most out of your work. Let that intent shine in your tone.

One way of granting power is to offer valuable information. If you explain the dynamics of a test process to a project team, then the team can use that information to "work the system" and get more of what they want from you. For instance, if the programmers understand the benefits of testability, they are more likely to design the product in ways that allow you to compress the testing schedule.

However, knowing about testing is not the only way you help your clients be more powerful. You also help them by not knowing and thus sharing the problem-solving process with them. In other words, an alternative to "I know what to do, listen while I explain it" is "I'm not sure what the best test strategy would be. Let's discuss our ideas and try something that seems reasonable." The latter is the attitude of a student of the craft, rather than an expert. A true student studies, wonders, listens, and works with other students to piece things together. The posture of a student conveys more of a sense of speculation than a tone of lecture. Oddly enough, the more expert I become in the logic of testing, the more I believe that what I know is primarily speculation.

Being a student requires that you come to terms with this basic truth: you might be wrong. It's because you know you could be wrong that your voice doesn't sound icy and condescending when you speak. You sound confident, but not insufferable. Because you know you could be wrong, you keep the smirk out of your voice when you say things like "It would be great if I could write a program that would automatically test this product; I just don't know how to do that."

The Hallway Dialogue
Explaining testing is a big subject. Here, let's focus on one part of the challenge: the hallway explanation. That's