Wednesday, February 11, 2009


The test group often finds ourselves the gateway between dev and other groups. Support, for example, comes to QA first when they can't figure something out. Sales comes to QA with a scenario and the question, "Can we handle this?" Product management comes to QA to ask about the state of a feature that marketing wants to demo.

As a consequence, we find ourselves translating a lot. 

Sometimes it is just different terms:

Marketing: "Permabit Enterprise Archive"
Dev: "clique" or "object store"
Support: "object store"

(Marketing changes names sometimes; dev just goes with what we've generally called it.)

Sometimes it's precision of ideas:

Sales: "When the object store is busy"
Support: "During an some authority transfers resulting from server removal"
Dev: "In phases 4 -7  of an uncontrolled leave"

Sometimes its other things, like avoiding sloppy the use of the word "crash" because that's a scary term to users and to sales.

A good test team will handle this translation seamlessly, using terms and phrasing based on the audience. Much like we are polyglots in the languages we use to code, we need to be polyglots in the language we use to describe features and problems. So look at your "to" list, or at the other attendees in your meeting, and choose your words considerately.


  1. QA work can from my experience be equal to communication. As a tester I ran into a situation where the main part of securing quality was not done by testing but by introducing myself as a translator between the development-team and other stakeholders with todo's.

    I wrote about it in swedish (thank Google for translate service ;)

  2. I completely agree with that. When I'm really successful in my current job, it's not because my team found a bug, but because we were able to explain what was going on and what the consequences of fixing the problem and of not fixing the problem were - all in terms that the sales engineers can take to their clients, or that allows product management to understand whether it's better to not release.

  3. In Bridging the Communications Gap it is well illustrated that while yes, we can be translators it is better to use a single, common vocabulary across the organization (and within the code as well). This is certainly daunting and can be a challenge for existing projects I can see how it would improve communications in most situations.

  4. Adam, I think that's a nice ideal, but the practicality of it is something I question. In rereading this, I think I've conflated two distinct concepts a bit:
    - sometimes people use different words for the same thing
    - sometimes a concept must be explained at different "altitudes" to match the understanding of the audience

    For the first, a common vocabulary is ideal, but part of our responsibility is to translate until we can get there. I think we wind up saying something like "a clique, an object store, is half full when blah blah blah" to continually associate both words, thereby bringing their shared meaning into our audience's heads. Over time, the differing terms (hopefully) fall away.

    The second issue is something that I think is more permanent, and that's okay. You have to describe a concept at the level your audience needs to know and is capable of understanding. I no more expect the sales guy to understand the ramifications of mutex handling in exception blocks than the sales guy expects me to be able to accurately describe the phases of a sales process (by the way, I can't!). There is some point at which we pitch the discussion to a level that allows all involved to make intelligent decisions.