There has been some recent debate about why and when “safety language” is used in test reporting, some of this stemming from a recent Rapid Software Testing course run by Michael Bolton and some from discussions with colleagues where I work.
What do we mean by safety language? Let’s take one of my favourite tests as an example, the Duck Test, and for the sake of this post, quote it directly from Wikipedia (with the understanding that there are sometimes variations in how it is written):
If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.
It’s the word “probably” that is our piece of safety language in this case. The tester has used information resulting from vision and audition (but sadly not gustation) to make a conclusion that the thing in question is “probably” a duck. Not definitely, not might be, but probably a duck.
By using that language, the tester is essentially allowing for some more information to come to light at a later date which might alter that conclusion. It’s possible that the impressionist will next get out of the pond and remove the duck costume, allowing the tester to say “Well now, it looks like a human, walks like a human and talks like a human, so it turns out that’s probably not a duck.” and still have made appropriate conclusions from their two assessments based on information available at the time.
The application and language here is used in reporting the issue to stakeholders or other interested parties and it’s the motivation for it and implications around it that are causes for concern.
James Thomas has stated his dislike of calling this safety language and that the choice of that name gives a sense of “covering your ass”. There is an element of that in many test reports, but I believe that is a natural result of the assertions being factual and honest. “I haven’t found any discrepancies”, “error X hasn’t occurred in 1000 runs since the change” and similar reports all do provide some leeway for the tester in the event of the essence of the report being found to be untrue, while at the same time the statements are appropriate ways of reporting something for which there is no certainty. Note that I’m not saying you should be constantly vague so as to duck out of committing to anything that’s reported, either.
We’ve looked at why but what about when? Continuing from the previous point: in some situations, I would say that a tester should have the confidence (personal and evidence-based) to make a statement that doesn’t utilise safety language in their assertion. To say things like “it works” and “the problem is fixed” are personally too vague to be appropriate, but I’d be confident and willing to state that the waddling, paddling, quacking, ten-inch high creature in front of me is a duck. (Aside: I have just searched online for “how tall is the average duck” before realising I was using DuckDuckGo to do so.)
For me, it’s acceptable in this context because primarily there remains no doubt in my mind about the conclusion but also because I believe others would make a similar conclusion from the evidence available. I wouldn’t expect to need to vehemently defend my assertion here to my questioner, were it to turn out that this thing shockingly wasn’t in fact a duck.
Lastly – partly because it would seem inappropriate not to include climbing somewhere in the first full post – let’s look at the following two sentences that might be said to a climber, about to start lead climbing a really scary route:
- I have visually checked everything I can see and it looks like your knot is correct and I’ve probably got you on belay but I can’t be certain so if you fall you may still hit the ground.
- You’re good to go, climb when ready.
One of those is factual, honest and ass-coveringly safe. One of those is what I want to hear if I’m the climber. Counterintuitively, safety language in this scenario makes me feel less safe and I’d prefer something a little less honest and a lot more confidence building, even if it is a fabrication.