A Term is a Term is a Term

Many testers, authors and consultants will deny it, but the specialized technical communities in general and perhaps the software industry in particular have reached the point where much of what is written seems deliberately designed to confuse the reader.

Those engaged in private industry's version of the academic "publish or perish" phenomenon find that they must write books, articles etc. which put their name before their peers. In order to get these items published they must have something unique to say or say the same thing in what seems to be a unique manner. Frequently, this uniqueness is developed by changing the terminology with which subjects are discussed, so it appears there is something radically new and valuable that the author is discussing. In fact, the author may have many things valuable to say but they do not necessarily need different terms with which to present them. The terms used are only labels for a concept. The item you think of as a "chair" could just as easily be called a "table". What’s important is what we think of when we hear the word and what we do with the object. In other words, the important thing is the understanding of the concept. However, each person who listens or reads has his/her own understanding of the word and the concept it represents. This inevitably leads to misunderstandings, heightened when the words are used in a slightly different way from that generally understood. As an example, in software testing there is a phase of the various testing tasks, levels or types generally referred to as Acceptance Testing. Most software testers think of this as the time when users or those people authorized to accept the software for end use enter the testing picture. At least one article has appeared in testing journals in which acceptance testing turned out to be that time when the software moved from development into a separate testing group and was thus "accepted into testing". Most confusing if the reader is not paying extremely close attention and thinking about the use and meaning of the words.

Each of us, in our environments must try to ensure that we understand what an author really means when a given term in used. If we are doing the writing we should remember that it is not necessary to change the labels in order to have something meaningful to say. Stick with the labels that you believe most of the industry understands. To be especially helpful include definitions of your terms with the article. Don't assume everyone uses the term in the same manner you do. Most of us find consistency very difficult to develop but when we do it generally saves us time and effort. Consistency in terminology would do the same for testing. If you feel strongly that there is some nuance of difference between two terms then be sure to define those terms for your reader so that he/she can comprehend your point. Examples of terms that I find to have what a professor of mine used to call "a distinction without a difference" are test suite, test scenario, test set or unit testing, component testing, module testing. Some organizations may indeed have meaningful differences between those sets of terms but I suspect most do not. The 17th Century philosopher Francois Voltaire has said "Men use thought only as authority for their injustice, and employ speech only to conceal their thoughts." This is not a helpful approach in our industry. Aim for clarity.

Above all, if you are a manager trying to find your place in the organization, don't do it by changing the terms, so that everyone who deals with your project has to work at the basic understanding of what you are doing. Make it easier for people, not harder. A recent Dilbert cartoon referred to the number of standards available. Sort of negates the term "standard" doesn’t it? In the interest of making it easier for all of us, lets try and make sure that our differences are true differences and not just window dressing. To facilitate comprehension variety is not the spice of life.