All industries have their own jargon practitioners use to communicate. Software testing surely has terminology most testers are familiar with and use to label artifacts frequently involved in their work. The problem becomes when testers hold too tightly to these labels, forgetting that the things they signify are what truly matters. It's important to remain flexible.
All industries have their own jargon practitioners use to communicate. The nuanced field of software testing is no different, and there is a certain terminology most testers are familiar with and use to label artifacts frequently involved in their work.
There are two basic camps involved in this labeling. One camp sees how labels can be used to capture the essence of a thing. When James Bach says automated testing is actually automated checking, he is trying to capture the perceived difference in activity. This is part of the very soul of science. Scientists box in life under items like genus and species in what they call classifications.
In the other camp, labeling represents a prison of a sort. They perceive labels as locking in your thinking. My grandmother experienced this when she first got a cordless phone. She would stand right next to the charging base as though the handset were corded. She had a label in her mind that said all phones require you to be next to the base. Cordless was not an idea she had actually connected to phones. Social scientists note that we associate simple things such as colors with gender, money, and when to stop or go.
The Power of a Label
The power of labels goes far beyond these simple matters, though. This is illustrated by the Rosenhan experiment performed in the 1970s about the reliability of psychiatric diagnoses. Psychologist David Rosenhan and seven other healthy associates feigned hallucinations in order to be admitted to psychiatric hospitals. Once admitted, they acted completely normally and told staff they felt fine enough to be released. Although it had all been a sham, the “patients” spent an average of nineteen days in their hospitals, and they all had to admit they were mentally ill and agree to take antipsychotic drugs in order to leave. Rosenhan was surprised by the results; despite evidence to the contrary, the hospital staff could not let go of the initial labels they gave to the experimenters.
These labels have real-world consequences in our thinking. In testing, we sometimes argue over whether software problems should be called bugs, issues, or defects. I have had developers tell me a usability problem is not a bug. They were locked into the idea that the label “bug” precluded usability, even though they agreed the usability “issue” was still a problem. It’s worth noting that I don’t concede that usability issues are not bugs! Some people are just more excited to debate the word than to fix the problem. We all can be.
This topic of labels is a deep and difficult one to unravel, and I can only touch the surface. Words are slippery and mean different things to different people. It’s what generates such overly long legal documents we use for laws and contracts. It’s why most bugs exist in the first place, be it due to a misunderstanding of what code syntax means to a given set of systems or what the requirements are to a given set of users.
There are two responses to this problem. The first is to try to carefully define every term. You might clarify that your definitions only apply in a particular context—what Bach calls a namespace. The second response is to say that words are just a rough drawing and that things should be loosely defined, if at all.
Do You Make Your Bed?
The attempt to make definitions important or arbitrary is akin to other debates we have in computer science. One example is what Steve Yegge likens to whether you’re the type of person who makes the bed every morning. He was differentiating between people who want things well defined, neat, and tidy and people who don’t care whether the bed is made and want to get more important things done. To him, they’re analogous to those who desire the neat, well-defined static typing with type safety and those who desire the flexibility and simplicity of dynamic typing. The “neat freaks,” as Yegge labeled them, would prefer a statically typed language because it made the definition really clear:
Button button = new Button();// No question about it. It’s a button!
The slobs, on the other hand, need not work hard and define the type; they prefer to let the system do it. He notes that slobs also get things done, just without worrying too much about the details. Studying the speed and quality of software development is difficult, but of the efforts done so far, it is not clear that any given language is substantially superior to another, except perhaps using a language that fits your mental and usage model.
Pardon my own reductionism, but ultimately, the scientific approach to labels is a sort of reductionism. We try to get more and more precise definitions with only the very rare breakthrough concept. Einstein redefining physics is not an everyday occurrence, but scientists measuring and adding precision is.
This reductionism, of course, comes at a price. We can forget that a label might not mean the same thing to others, creating namespaces that only insiders understand. We can apply the labels in our thinking subconsciously, and when the world changes, we are slow to adapt. People can’t just permanently delete a concept from their brains once it becomes obsolete to the rest of the world. Labels can work well as mental shortcuts, but if they are not re-examined occasionally, they’ll cause you to miss the mark.
Keep Some Perspective and an Open Mind
In testing, I know some of the so-called “schools of thought” within the discipline resent being called “schools of thought." On the other hand, we do need labels to help us clarify a concept, even if the label is not the same as what someone else would use. As a human, I must label ideas in order to document them and generate discussion. As a tester, sometimes I write bugs for that very purpose!
The question these realizations should generate for us as a group is, Why are we so stuck on labels, and what can we do about it? First, it’s important to recognize that it is the idea behind the label, not the label itself, that matters. In order to grow, we must be open to criticism of our labels, as they carry unintended weight. While I do have some flexibility in using a namespace where I work, I can’t expect that the namespace will make sense to every other tester I interact with. Though I know my labels are shortcuts, it doesn’t stop me from making poor assumptions from time to time.
We must all make a conscious effort to use labels only for further clarity, not to be trapped in the prison of using them as absolutes. What labels have been holding you back?