In late 2010 I heard from my colleague Stefan Roock who organized some Story Test Workshops, or – rather – Story Test Dojos. At one client, he asked to write collaboratively story tests using the Given/When/Then schema from the behavior-driven development. However, he experienced one fallacy there, which one of the Product Owner fell into.
Though, the technique was introduced in English – or maybe just because of that – there was a confusion about the meaning of the “When” part of the format. Now, when translating “When” to German, there are two possible meanings – the resulting word is “wenn” in either case. One meaning is the right one, the temporal “wenn”, as in “when I press the button”. The other possible translation is a causal if, like in “if I press the button”.
Now, what confused the story tests was the occurrence of the causal meaning of the “when” part. “Given a user interface, when I press the button, then something happens” now gets two different meanings – depending on how I translate and interpret it. While there is one translation which is in the sense of the inventors, there is yet another, which adds complexity.
The causal meaning adds complexity to the interpretation of the test. If I interpret it the “When” part as a causal meaning, I get a condition into my tests. The flow through the story test gets split up into two branches. One where the condition in the causal “When” part is met, and one where it isn’t. Besides the fact that no reasonable Agile-friendly tool interprets the “When” part in this manner, the resulting tests get confusing, since they basically have to evaluate two branches.
Now, I challenged this fallacy over twitter, and Olaf Lewitz fired up some possible alternatives to “When” or “Wenn” in German. One alternative was to use “anlässlich”, which reveals the purpose of the following step. The problem I have with “anlässlich” is, that it gets confusing, since it’s such an unsually used word, and might further deepen the confusion around the term. Another proposed alternative was to use “sobald”, which could be a good one, but is also rather unusually used.
This week I had the opportunity to visit this particular client. While conducting a story test dojo on my own, the confused product owner was not present, unfortunately. Yet, I tried to bring in the alternatives as Setup-Execute-Verify from the xUnit Test Patterns book, as well as the Build-Operate-Check from the FitNesse UserGuide. These alternatives helped to understand the active part of the second phase.
However, what can we learn from this? An approach aimed at getting ambiguities out of the user stories might contain ambiguous elements in itself. Maybe this just happens for one out of hundred Germans who cross this approach, still it might happen. There is one way to overcome this with training, and mentoring. Just like we overcome the ambiguities in user stories, by collaboration and communication, we overcome the same short-comings in the same way by using education, communication and collaboration.