When you hear the word ‘test’, what does that mean to you? (If you just said ‘it depends’, congratulations, you’ve earned your ‘consultant’s answer to everything’ badge). When folks who aren’t career software testers use the word ‘test’, it frequently comes with a raft of associations that are decidedly different to what many software testers mean when we say test. It’s not really so surprising. It’s not like software testers coined the term, or have some sort of special ownership of its definition. Testing is a thing that exists far beyond software and has existed as a concept since early primates tried eating random stuff to see what would happen.
In our industry, these differences in understanding means that the word test (and ‘testing’ and ‘tester’, and ‘QA’…) has the same sort of industry baggage that words like ‘estimate’ have. We know that when we’re asked for an estimate, what people frequently mean is ‘immutable promise’. By the same token, testing is often seen as ‘that thing that happens at the end’ or ‘just unit tests’ or some other oversimplification that misses the vast majority of the craft.
Given time and exposure to skilled, articulate testers, or perhaps trial-by-fire in the complete absence of testers, non-testers can learn to see the depth and breadth of the discipline. It can be a hard sell though, and it would be easy to conclude that the vast majority tend to switch off when you try and explain, because they’re just not incentivised to give a shit. That would be a mistake and a total cop out. If I buy into that stance, I give up my agency to do something about it. Let’s go back to test reporting 101 – Your testing is only as good as your ability to report it to someone that matters in a way they can consume and act on.
The message ‘testing is shitloads more deep and complex than you realise’ is not landing and has been steadily not landing for a really long time now. The verb ‘test’ is massively overloaded. When I say test, there is absolutely no guarantee that my audience will have the same frame of reference as the one I’m using. Indeed, when I’m coaching teams to highlight issues in testing and quality, I challenge them to describe their testing activities without using the word testing. It’s initially quite difficult, and the tendency seems to be to simply not talk about testing at all, but it does highlight how much of a blanket term ‘testing’ is. No surprise then that both the activity and the craft have such a wide range of definitions.
It’s not enough to simply say ‘use a word other than testing’ – it’s an effort to find alternative vocabulary and the reward for doing so is occasionally a lecture about how you’re doing it wrong by definition police. Testers have been quite good at coming up with alternative vocabulary to describe testing activities. That can work for career testers who are speaking with other testers, but the occasional obscurity of this language can be a barrier to entry for non-testers to whom these words are unfamiliar, or differently understood. Let’s look at a simple example. When I say the word ‘charter’ in a testing context, It’s highly likely that I mean an exploratory testing charter. When we talk about testing charters, we’re using it in the sense of a ‘charter tour’. We use it to mean a mission and a time box to provide framework within which we can structure exploratory testing. If we look at the dictionary definition of the word charter, the definition we use is not the first that crops up. I’ve spoken to a few people who were bothered by the word ‘charter’, and it took about 2 seconds to explain, but it wasn’t a term that readily sat with people. One person said ‘Why don’t you just say ‘test mission’? – and that’s pretty much what I did. I lost nothing and gained immediate clarity for that audience.
It is important that we are mindful of how our peers take on new information; that we’re inclusive with our language and couch our reporting in terms they’re familiar with. Introduce new terminology sure, but not without giving people time to take on the concepts you’re talking about.
In my post about team dynamics, I could have named the Research and Experimentation sphere ‘Testing’, but it would have been poorer for it. It would have masked other activities and areas that are also information radiators, who also conduct experiments and who seek to probe complexity understand unknown unknowns. I have been finding that describing testing as research and experimentation seems to land with people as it is an activity that they can readily imagine and one whose value maps well to software development. I’m not suggesting we should all drop the term testing and replace it with R&E, but do be aware of the language you are using and the power that it has to open up or close off or reframe conversation. Remember your test reporting skills and speak the language of your audience.