Test Is a Four-Letter Word

During a twelve-year period of teaching software testing seminars around the world, I asked the attendees the following questions:

"When was the first time you heard the word test?"

"Where were you when you first heard the word test?"

"How did the word test make you feel?"

Most of the responses were similar to "It was my third-grade teacher at school, and I felt nervous and afraid."

Now there were a few exceptions, such as "It was my third-grade teacher, and I was happy and excited to show how smart I was."

But by and large, my informal survey found that "test" is a word to which most people attach negative meanings based on its historical context. So why is this important to those of us in the software development business? Because I have found that a preponderance of software developers do not get excited when they hear that the software they just wrote is going to be "tested" by the test group. Typical reactions I have heard over the years run from ...

have heard over the years run from . . . "I'm sure there is nothing wrong with the software, so go ahead and test it; better you find defects than our customers."

... to these extremes ...

"You are not qualified to test my software because you don't know as much as I do about it."

"If any test engineers come into our office again to test our software, we will throw them through the third-floor window."

Why is there such a strong negative reaction to testing? It is primitive. It goes back to grade school for many of us, and it’s hard for most of us to reprogram associations learned at an early age. It is a word that conjures up negative emotions. In other words, "test" is a four-letter word. So what can we do about it (short of hypnotherapy for software developers)? Well, one concept I use is to refrain from calling testing "testing." Call it something else. Ever wonder why most independent software testing groups are called software quality assurance groups? Now you know. Software quality assurance is not such a negatively charged phrase, although it is important to note that software quality assurance is much more than simply testing.

In my current job, working at a national laboratory with world-renowned physicists, I again have encountered negativity about testing software. Testing software takes time and gets in the way of completing ground-breaking science experiments. In the physics-dominated world, I found out—the hard way—that if I requested more time to do software experimentation, the physicists' resistance melted. And so the conversation continues, "We have time to run more software experiments. Just don't waste any more time testing the software!"

If the concept of calling testing by another name appeals to you, there may be a way for you to take the sting out of the name in your workplace. I have compiled a table of alternative terms for testing. (See Figure 1.) To come up with substitute names for testing, pick a word from each of the columns in the Don't-Call-It-Testing table. For instance, Unified Acceptance Trials (A2, B7, C3). You can probably think of some additional combinations appropriate to your industry.

Now that there are possible alternatives to using the grating word “test,” we still have to deal with what to call the situation that exists when the expected result of running the test (experiment, study, examination, etc.) does not agree with the actual result. Common words currently used to describe this situation are "bug," "defect," "failure," "fault," or the