Is it time to watch your language?

Zachary Borrelli
By Zachary Borrelli under Agile, Insights 30 June 2016

As testers at TAB, we build strong lines of communication with everyone in our teams, across all stages of a project’s lifecycle. This is because part of a tester’s main job is to know what’s going on at all times at every stage of a project and to help communicate that back to the team - I think of us as ‘information brokers’, if you like.

In order to glean this information, efficient and valuable communication is compulsory. When thinking about how to ensure meetings or knowledge transfer sessions are succinct and understandable, I often think that the subtleties of language are overlooked. At TAB, we are always thinking about the little details, and so with that in mind, I wanted to dig a little deeper into language - and the words we use to structure our teams, our questions and answers.

TAB itself was built on the belief that exceptional technology experiences require different disciplines to sit together - under one roof, and around one table in product teams. As a result, we work hard to ensure everyone is speaking a common language - because without this, when meaning can be misconstrued, code can be become unreadable, processes buckle and email chains extend way past their intended length.

Accept that language can become stale

We all know there are a huge number of overused buzzwords in business - from synergy, marketability and transformation to my own current favourite business phrase: ‘run it up the flagpole.’ (Don’t ask). These buzzwords become amusing cliches because of their overuse, eventually rendering them meaningless and hollow. This is language past it’s sell-by date.

The testing world, too, suffers from stale language, and the main culprit being the term ‘QA’. QA stands for Quality Assurance, and for many people, is synonymous with the idea of testing. As a test engineer, for me, however, it’s a term that is very ambiguous and has a lot of bad connotations - it’s also a word that we have challenged, and rethought, here at TAB.

Say it out loud, for example. ‘Has this been QA’d?’ makes little to no sense. Break it down, and it would sound something like ‘...has this been Quality Assuranced?’, or perhaps even ‘...has this been Quality Assured?’

Leave aside the grammar for a moment, and you are still left with a very subjective question. Whose quality are we assuring ‘it’ by? How much quality can we assure? How do we know when to stop assuring quality? On the outside, these seem like simple or even irrelevant questions, but probe further and you will notice blurred lines, and yet more vague language.

It isn’t uncommon by any stretch for companies to take quality so seriously, they set up a separate QA team to police it - and when it comes to software development, that team is frequently made up of testers. At TAB, however, we believe that every team member is in charge of quality: it isn’t just something you can throw over the fence for testers to check for at the end of a project. With everyone committed to quality, therefore, there is no separate QA ‘team’ because technically, we are all part of it.

If we also change the term QA to ‘testing’, we instantly start to get more tangible questions, with much more specific answers. We can ask ourselves whether something has been tested, against what and by how much. Just by switching a two letter abbreviation with multiple meanings to a verb we can more readily define and quantify, the language around this subject has become a lot easier to understand. So, in turn, have our processes and ways of working.

With the use of testing instead of QA, we can more readily see the lines of who does what and where the focus of each role lies. When testers stop being called the QA team, and quality becomes the responsibility of everyone - from designers, to POs and developers - we can get back to what we do best: being the people whose responsibility it is to test (surprise), challenge and explore. We can focus on specific tools and techniques, such as exploratory and automation testing, or the use of Calabash, and get back to being the ‘information brokers’ I referred to earlier.

Testers need to know as much about a product as possible, because in doing so, we can help gauge and inform the team about the level of quality (good or bad) in a product - ranging from the size of a button on a screen, to the implementation of acceptance criteria.

Know when language needs to be discussed

When discussing language in this manner, there is admittedly a fine line between semantics, and pinpointing an area that actually needs attention. The point is, though, to be unafraid to identify and challenge language when we sense words have begun to lose meaning, or even hold us back.

As testers at TAB, we learned from experience that QA didn’t convey what we knew testing was really about, and we pulled the cord to prevent it being applied without sufficient thought to what it means to our delivery process.

To combat this internally, we have run learning sessions around changing terminology - not just in our own community of practice, but with other disciplines as well. This means we stay alert to the meaning and value of the terms we use, challenging the wording of a wide variety of artefacts and processes - from release forms and scrum boards, to job descriptions. Even when we decide we don’t need to change a name or describe a process differently, the key point is that we regularly inspect, test and adapt not only our products, but our own terminology.

Changing our language internally is one challenge, changing terminology within our client teams is another. To evolve our clients’ language - for example when they ask for ‘QA engineers’ - we progressively work with them to solidify meaning, and change misconceptions as consistently as we can to ensure we are both speaking the same language.

Planting small seeds like this, and being consistent in the planting of them, is a long-term game. Eventually, we start to see bigger changes come into effect amongst our clients - like the adoption of the word testing over QA from the start.

Recap

Ultimately, by aligning the language we use when communicating, we ensure that everyone is on the same page - whether that’s internally, or externally. Then, when talking to each other, we can be confident that meaning isn’t being lost through translation, and knowledge is properly transferred.

The term ‘QA’ is my working example of this, and I would love to know if you, too, think the term QA has lost it’s meaning. What other commonly used terms does your organisation need to rethink? Let me know directly by tweeting @zacoid55.