Acceptance tests: Lost in translation

Development/Tech, Digital, Opinion, Project management


The problem

When my parents were on their honeymoon, staying in a hotel in Cairo, they found a notice on the inside of the hotel room door. It read:

“Breakfast is compulsory.”

Clearly, there was a gap between what the sign said, and what it was actually intended to mean. The person who wanted to convey the message didn’t speak english, so they had asked someone to translate for them. The person who did the translation had a slightly different view of the meaning than the originator. The message ended up meaning something very different to my parents than it was intended to (and gave them a good laugh).

The same thing can happen in software projects. When requirements are translated into specifications, which are in turn translated into acceptance test cases, there is always potential for things to get lost in translation. This is particularly problematic in traditional waterfall style projects, but can certainly affect agile projects too. The end result is a difference in understanding between the testers and the people creating the requirements. In the worst cases, this can result in bugs not being discovered and the wrong things being tested.

A solution

In my parents’ case, it might have been easier if they spoke Arabic, rather than relying on a poor translation. In software projects too, the solution can be just as simple: Don’t translate.

Gherkin syntax

Gherkin syntax is a central part of the cucumber BBD framework, but even out of that context, it is a useful way of expressing acceptance tests in a user story. The syntax is simple:

Scenario: Some determinable business situation:

Given some precondition
And some other precondition
When some action by the actor
And some other action
And yet another action
Then some testable outcome is achieved
And something else we can check happens too

There are very few rules:

  1. You can only have one each of ‘Given’, ‘When’ and ‘Then’
  2. You can use as many ‘And’s as you need to

As can be seen, this is clear, understandable and unambiguous for everyone – the business analysts, the developers and the testers. Just as importantly (perhaps even more so), it’s easily readable by the project manager and the product owner.

This means that we can use this syntax to specify acceptance tests in the user stories, right from the beginning. It doesn’t need to be translated, and so we don’t run the risk of errors creeping in. Because the format is natural language based, it’s easy for everyone in the team to understand.

Taking it forward

Obviously, specifying acceptance tests in a clear, understandable format is already ‘A Good Thing’. Taking another step releases even more benefits. Using a tool, like robot framework, allows the tests to be easily automated, again without the need for translation.

Using this method, acceptance tests can be expressed in the same way throughout the story life-cycle – from story writing to reporting on automated test results. This gives greater clarity at all stages of the process, to all people involved. Greater clarity means fewer bugs being missed or introduced because of different interpretations of acceptance tests.

There is also a significant time saving to be made. Because we are using the same language to express our tests all the way through the process, we no longer have to use precious time and resource translating (and dealing with the confusion that this can cause).


Oh, and the sign in the hotel? Apparently it should have said “Breakfast is complimentary”…