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 means Quality Assurance, and for many people, is synonymous with the idea of software 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 Kin + Carta.
So, what does QA mean? 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 software testers. At Kin + Carta, 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’ for software testing 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 software 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.