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?
User Comments
I thought that was a nice article, JCD.
“Semantics and the Risk of Labels”
This is a topic that is very interesting to me, even outside the context of “software testing”. I was reminded of many ideas while reading your article…
“This topic of labels is a deep and difficult one to unravel, and I can only touch the surface.”
Indeed. Some folks spend their entire career, and/or much of their lives, studying only this topic. I’m not one of them, but I’ve read and learned a lot about it.
“One camp sees how labels can be used to capture the essence of a thing.”
This reminds me of “intension” (https://en.wikipedia.org/wiki/Intension), and Intensional Definitions (https://en.wikipedia.org/wiki/Extensional_and_intensional_definitions#In...).
“Scientists box in life under items like genus and species in what they call classifications”
This reminds me of Richard Feynman explaining the difference between Naming & Knowing (https://haveabit.com/feynman/knowing-the-name-of-something/), and similar quotes by William Shakespeare (“A rose by any other name would smell as sweet”) and Gertrude Stein (“Rose is a rose is a rose is a rose” both referencing the Law of Identity (https://en.wikipedia.org/wiki/Law_of_identity).
“In the other camp, labeling represents a prison of a sort.”
That reminds me of quotes from Edward de Bono ("In a sense, words are encyclopedias of ignorance because they freeze perceptions at one moment in history and then insist we continue to use these frozen perceptions when we should be doing better."), John Ralston Saul (“Dictionary – Opinion expressed as truth in alphabetical order”), and Søren Kierkegaard (“Once you label me you negate me.”)
“We can forget that a label might not mean the same thing to others, creating namespaces that only insiders understand.”
This reminded me of Linguistic Relativity (https://en.wikipedia.org/wiki/Linguistic_relativity), Cultural Communication (https://en.wikipedia.org/wiki/Cultural_communication), and quotes from Tony Robbins (“To effectively communicate, we must realize that we are all different in the way we perceive the world and use this understanding as a guide to our communication with others.”) and Ludwig Wittgenstein (“The limits of my language means the limits of my world”).
"whether you’re the type of person who makes the bed every morning."
That sounds like a lot of work. First, you'll need a hammer and saw... J
Wow, I appreciate your enthusiasm.
I didn't want to delve too much in the theory in this article, but as you demonstrate via your wiki links, this is a nontrivial subject. I could have started with metaphysics, identity and what is reality (https://en.wikipedia.org/wiki/Metaphysics ) but for most people, defining and questioning these base assumptions are of less interest. Also, the further afield I go from testing the less likely I would be published in this sort of forum. That being said, I appreciate that you helped annotate my article with your links.
While I do see connections between, say, Rene Descartes, Karl Popper and Noam Chomsky to our work, their study of thought in various forms are tangential to our day to day work. I would encourage someone whom wants to deeply understand our profession to study these subjects, as well as others. Yet I don't think I could easily rank which subjects would be the most valuable for a given person, as that depends on context. Furthermore, the skill set of the audience must be accounted for, which I apply the Dreyfus model of skill acquisition to my writing. To further the goal of education, I generally try to write higher-level articles here and blog on deeper subjects, as I have time and energy. Based upon your interest, you might find https://about98percentdone.blogspot.com/2015/04/tainters-composite.html of interest.
Since you ended with a joke, let me return the favor. Rene Descartes walks into a bar and the bar tender asks if he would like a beer. Descartes says, “I think not!” and disappears in a puff of logic.
- JCD
Wow, I appreciate your enthusiasm. I apologize for the slow response but Stickyminds had a bug where I couldn't post! Very frustrating indeed.
I didn't want to delve too much in the theory in this article, but as you demonstrate via your wiki links, this is a nontrivial subject. I could have started with metaphysics, identity and what is reality (https://en.wikipedia.org/wiki/Metaphysics ) but for most people, defining and questioning these base assumptions are of less interest. Also, the further afield I go from testing the less likely I would be published in this sort of forum. That being said, I appreciate that you helped annotate my article with your links.
While I do see connections between, say, René Descartes, Karl Popper and Noam Chomsky to our work, their study of thought in various forms are tangential to our day to day work. I would encourage someone whom wants to deeply understand our profession to study these thinkers, as well as others. Yet I don't think I could easily rank which subjects would be the most valuable for a given person, as that depends on context. Furthermore, the skill set of the audience must be accounted for, which I apply the Dreyfus model of skill acquisition to my writing. To further the goal of education, I generally try to write higher-level articles here and blog on deeper subjects, as I have time and energy. Based upon your interest, you might find https://about98percentdone.blogspot.com/2015/04/tainters-composite.html of interest.
Since you ended with a joke, let me return the favor. René Descartes walks into a bar and the bar tender asks if he would like a beer. Descartes says, “I think not!” and disappears in a puff of logic.
- JCD
I apologize for *my* slow response, but I had a bug where I get lazy. :)
<I would encourage someone whom wants to deeply understand our profession to study these thinkers, as well as others. >
Hear, hear! I enjoy studying, thinking about, and discussing with others, the deep, underlying ideas behind many common testing topics.
<and blog on deeper subject>
Thanks for the reminder! I'm currently re-discovering your blog.
<Based upon your interest>
I am! Thanks for the tips. I've (finally!) started reading the Gervais Principle, and will devour your other recommendations, in turn.
The labels I use are part of my project to rescue the testing world from bullshit. I seek precision in my language just as lawyers and doctors do, and for exactly the same reasons.
I hope that my efforts liberate testers from the prison they are already in.
The ISTQB promotes a vocabulary that they believe should standard for everyone. It's poorly designed-- the surgical equivalent of dull and rusty scalpels. I think you should speak out against that.
BTW, "automation tester" is kind of a clever label.
I apologize for the slow response but Stickyminds had a bug where I couldn't post! Fortunately, I did keep a copy of the post, so it wasn't lost.
I appreciate your mission and your work to reify your thinking through writing and creating definitions. You've done a service to our profession though your work, and I have benefitted from your work. Thank you. However, I'd be careful about idealizing the other professions. Legislation is often thrown out by court rulings for being vague and doctors using Latin words and acronyms to avoid their patients understanding their more blunt meaning (http://news.bbc.co.uk/2/hi/health/3159813.stm ), to name but a few problems. While categories are useful for scientific purposes, they also trap our thinking. Consider Ignaz Semmelweis, famous for noticing that hand washing appeared to lower the number of deaths in a hospital he worked at. However, because doctors were "gentleman" and the presiding ideas of the time, this innovation was ignored (https://en.wikipedia.org/wiki/Ignaz_Semmelweis#Conflict_with_established_medical_opinion ). I'm not suggesting these models do not provide value, nor that you have not considered these problems, although I have not seen recent written examples of you addressing these sorts of pit-falls. If you have, please, provide the link, I'd enjoy reading such an article.
I personally do prefer the weaker context-oriented system to the overly well-made bed that the ISTQB promotes. That does not mean they are not humans, some of whom likely come from good motives. While I find their methods to be less valuable, that does not mean they are devoid of value. To use a classic joke, there are two kinds of people in the world: Those who divide everybody into two kinds of people, and those who don't. However, my thoughts were not some much about the ISTQB compared to the context driven approach. When I was writing this, I was more pondering the division between testing as art compared to testing as science. Artist’s general capture an angle and attempt to communicate it to others through a medium. If testing is a performance (an analogy you used before, http://www.satisfice.com/blog/archives/1346 ), the terminology of the technique matters less than the usage of the technique. In fact, trying to define the art is often an annoyance to an artist. For example, authors sometimes complain that their book is placed in a particular bookshelf when they felt it was something else. Scott Adam’s God's Debris comes to mind, as he considered it more a philosophy book but it ended up in the religious section of some bookstores. I simply was trying to capture a small chunk of a much bigger and deeper discussion and put it out there.
The fact that I used you’re checking and testing as an examplar is more related to my personal interests as an “automated tester”. I have watched your process, such as https://watirmelon.com/2014/01/17/checking-is-testing/#comment-9218 . I appreciate your position of making better theory. I do have some critical opinions on your theory, some of which I have addressed in my blog and some I addressed with you at a past CAST. That being said, I also don’t feel the need to make everyone see the same point of view as myself. It is why I think the idea of a namespace is so brilliant and I heartily approve of that concept. It gives someone the ability to walk away from a set of assumptions by simply changing namespaces. The human mind does not seem to work well that way, often due to how system 1 works, but it at least gives system 2 a method to re-examine our thinking (https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow ). Hopefully you were able to use system 2 to cast my words to your namespace, even if it isn't your default namespace.
Thanks for your comment!
- JCD
(I have received a lengthy and thoughtful reply from the author, offline. Apparently some bug prevented it from getting posted here.) -- james
Michael Fine wrote in his book "Beta Testing for better Software" an excellent definition of what constitutes a bug. Anything that negatively impacts the user experience is considered a bug. In my opinion that ranges from spelling errors in the About dialog to design flaws. I encounter debates about "this is not a bug" when the code does exactly what was asked for, but the design is flawed. Yes, the developer did everything right, but she or he is still in charge of fixing the issue. As often I experience long debates about priority of bug fixing, typically using up more time than it takes to fix the issue. I'm perfectly fine with developers cherry pick the easy stuff first. This gets those issues off the list and leaves the few items that are indeed worthy of further discussion.
Key is to tackle any defect reports as soon as they come up. Leaving things as is and "hitting it next iteration" is the sure path to a very miserable place. Design it, code it, test it, fix it, ship it, get feedback, improve it. That is the path to follow. I have no idea why always the "fix it" part is taken out of that chain.
On several occassions I have found that if I call something an issue rather than a bug, the developer calms down. There is a power in the word. For instance, in writing this very article, I used the word unconcious, but the editor felt that subconcious was a better term, even though they mean the same thing. Perhaps that change did in fact make it clearer. I find that words pick up unintended meanings over time and through culture. Modifying one's language to use different but equivelant words sometimes makes a big difference in how the listener reacts.
- JCD