Blog: Common Languages Ain’t So Common

A friend told me about a payment system he worked on once. In the system models (and in the source code), the person sending notification of a pending payment was the payer. The person who got that notice was called the payee. That person could designate somone else—the recipient—to pick up the money. The transfer agent would credit the account of the recipient, and debit the account of the person who sent notification—the payer, who at that point in the model suddenly became known as the sender. So, to make that clear: the payer sends email to the payee, who receives it. The sender pays money to the recipient (who accepts the payment.) Got that clear? It turns out there was a logical, historical reason for all this. Everything seemed okay at the beginning of the project; there was one entity named “payer” and another named “payee”. Payer A and Payee B exchanged both email and money, until someone realized that B might give someone else, C, the right to pick up the money. Needing another word for C, the development group settled on “recipient”, and then added “sender” to the model for symmetry, even though there was no real way for A to split into two roles as B had. Uh, so far.

There’s a pro-certification argument that keeps coming back to the discussion like raccoons to a garage: the claim that, whatever its flaws, “at least certification training provides us with a common language for testing.” It’s bizarre enough that some people tout this rationalization; it’s even weirder that people accept it without argument. Fortunately, there’s an appropriate and accurate response: No, it doesn’t. The “common language” argument is riddled with problems, several of which on their own would be showstoppers.

  • Which certification training, specifically, gives us a common language for testing? Aren’t there several different certification tribes? Do they all speak the same language? Do they agree, or disagree on the “common language”? What if we believe certification tribes present (at best) a shallow understanding and a shallow description of the ideas that they’re describing?
  • Who is the “us” referred to in the claim? Some might argue that “us” refers to the testing “industry”, but there isn’t one. Testing is practiced in dozens of industries, each with its own contexts, problems, and jargon.
  • Maybe “us” refers to our organization, or our development shop. Yet within our own organization, which testers have attended the training? Of those, has everyone bought into the common language? Have people learned the material for practical purposes, or have they learned it simply to pass the certification exam? Who remembers it after the exam? For how long? Even if they remember it, do they always and everafter use the language that has been taught in the class?
  • While we’re at it, have the programmers attended the classes? The managers? The product owners? Have they bought in too?
  • With that last question still hanging, who within the organization decides how we’ll label things? How does the idea of a universal language for testing fit with the notion of the self-organizing team? Shouldn’t choices about domain-specific terms in domain-specific teams be up to those teams, and specific to those domains?
  • What’s the difference between naming something and knowing something? It’s easy enough to remember a label, but what’s the underlying idea? Terms of art are labels for constructs—categories, concepts, ideas, thought-stuff. What’s in and what’s out with respect to a given category or label? Does a “common language” give us a deep understanding of such things? Please, please have a look at Richard Feynman’s take on differences between naming and knowing, http://www.youtube.com/watch?v=05WS0WN7zMQ.
  • The certification scheme has representatives from over 25 different countries, and must be translated into a roughly equivalent number of languages. Who translates? How good are the translations?
  • What happens when our understanding evolves? Exploratory testing, in some literature, is equated with “ad hoc” testing, or (worse) “error guessing”. In the 1990s, James Bach and Cem Kaner described exploratory testing as “simultaneous test design, test execution, and learning”. In 2006, participants in the Workshop on Heuristic and Exploratory Techniques discussed and elaborated their ideas on exploratory testing. Each contributed a piece to a definition synthesized by Cem Kaner: “Exploratory software testing is a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the value of her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.” That doesn’t roll off the tonque quite so quickly, but it’s a much more thorough treatment of the idea, identifying exploratory testing as an approach, a way that you do something, rather than something that you do. Exploratory work is going on all the time in any kind of complex cognitive activity, and our understanding of the work and of exploration itself evolves (as we’ve pointed out here, and here, and here, and here, and here.). Just as everyday, general-purpose languages adopt new words and ideas, so do the languages that we use in our crafts, in our communities, and with our clients.

In software development, we’re always solving new problems. Those new problems may involve people to work with entirely new technological or business domains, or to bridge existing domains with new interactions and new relationships. What happens when people don’t have a common language for testing, or for anything else in that kind of development process? Answer: they work it out. As Peter Galison notes in his work on trading zones, “Cultures in interaction frequently establish contact languages, systems of discourse that can vary from the most function-specific jargons, through semispecific pidgins, to full-fledged creoles rich enough to support activities as complex as poetry and metalinguistic reflection.”  Each person in a development group brings elements of his or her culture along for the ride; each project community develops its own culture and its own language.

Yes, we do need common languages for testing (note the plural), but that commonality should be local, not global. Anthropology shows us that meaningful language develops organically when people gather for a common purpose in a particular context. Just as we need testing that is specific to a given context, we need terms that are that way too. So instead of focusing training on memorizing glossary entries, let’s teach testers more about the relationships between words and ideas. Let’s challenge each other to speak and to listen precisely, and to ask better questions about the language we’re using, and to be wary of how words might be fooling us. And let us, like responsible professionals and thinking human beings, develop and refine language as it suits our purposes as we interact with our colleagues—which means rejecting the idea of having canned, context-free, and deeply problematic language imposed upon us.

Follow-up, 2014-08-24: This post has been slightly edited to respond to a troubling fact: the certificationists have transmogrified into the standardisers. Here’s a petition where you can add your voice to stop this egregious rent-seeking.

Want to know more? Learn about Rapid Software Testing classes here.

12 responses to “Common Languages Ain’t So Common”

  1. AlexR says:

    Hi Michael,

    I think you have a very good point here.

    When I first moved to Finland, I made an appointment to a doctor for Next Wednesday – I was calling on Monday. Four days later I got a bill for the time I had reserved, and didn’t use. It seemed that NEXT really meant THIS in Finland, apparently due to the way the Finnish language handles these concepts.

    So my English and the nurse’s English was not really the same, even though we used the same “labels” to express our thoughts…

    Nowadays, whenever I make an appointment I ask the date and time.
    But even that might not work everywhere, as I heard from a friend that has been living in Ethiopia for some time. Apparently they have their own time system and calendar, so when you make an appointment you must also confirm the calendar and the time system (European/International or Ethiopian), to increase the chases that you got it right :).

    Alex

  2. Andrew Robins says:

    Hi Michael

    Last week I facilitated a workshop on system testing for my current employer. The first five minutes of the workshop were spent on discussing the various different ways we use the term “system testing” within the company.

    We came up with five different definitions in use in one company.

    I used this example as a way of reinforcing the concept of the importance of assessing context, and of checking assumptions.

    I did not tell the people in the room that they had to invest their time and effort in convincing everyone that their definition of “system testing” was correct, and everyone else’s was wrong.

    I have always found it much more useful to seek to understand the terms that others are using, and why they are using them in that way. You might end up disagreeing with them, but you are probably going to learn something along the way

  3. Antoinette Panico says:

    Couldn’t agree more with you Michael. I ‘got certified’ as a requirement from my employer – we all did it. The hardest part of it wasn’t getting correct answers on questions that actually related to testing, but for me to adopt the language of the ‘certification body’ (QAI). I felt that their terminology.

    I had to study to relate their terminology to what I had always used. The fact that I had to use so many quotations proves my point 🙂

    Andrew, I agree that the discussion has to happen, but in order to communicate clearly within a team, they do have to agree on what it means to them as a team.

  4. Andrew Robins says:

    Hi Antionette

    Sure, I agree completely – but I just accept that part of the process I go through with each new group of people I work with is figuring out what they really mean when they use words I think I understand.

    I can still get blind sided on occasion, but I try to look on this as an opportunity to learn something new when it happens.

    Cheers

    Andrew

  5. […] summarize this epiphany (and likely will in a future talk), but for now I’ll let Michael do that for me here with […]

  6. […] terminology is dangerous. Read Michael Bolton posts about it here and here. To be able to truly understand each other, we need to ask questions and discuss in depth. […]

  7. […] the common language argument. It doesn’t help and is dangerous. Read what Michael Bolton about it here and here. Real testing skills cannot be learned by reading books. And I talk about skills like: […]

  8. Bela LeGates says:

    FYI, the link for Richard Feynman interview is blocked by BBC on copyright grounds. Found another link for the same video though at https://www.youtube.com/watch?v=WkbuJNpxmqs. OR http://www.haveabit.com/feynman/2

    Thanks.

  9. […] Common Languages Ain’t So Common by Michael Bolton […]

  10. Bernie Berger says:

    Did you know that if you asked someone from India the arithmetic question “How much is two into four”, there’s a good chance they will answer “eight”? I recently learned that “into” in this context, for people educated in India means multiplied by. My Indian friends were as surprised to learn that my American education taught me to interpret that as “what is four divided by two” as I was that they used that term as a synonym for multiplication.

  11. […] “prove to have foundation” Foundation? What foundation? You learn a few terms/definitions and an over-simplified “standard” process? And how important is this anyway? Also the argument of an common language is nicely debunked by Michael Bolton here: “Common languages aint so common“ […]

Leave a Reply

Your email address will not be published. Required fields are marked *