Wait, you say, when has cucumber, a common vegetable, grown into a communication vehicle? Well, I'm talking about Cucumber with a capitol C, a framework for test automation invented by an Icelander with a hard-to-remember name, Aslak Hellesøy. Aslak's big idea is that behavior of a system can be described in formal language fully comprehensible by mere mortals that are blissfully ignorant of mere existence of programming languages, and yet be convertible into a precise set of instructions used to fully execute tests by computers. Aslak called this language Gherkin (after a particular sub-species of cucumber).
In my experience, in order to use Cucumber effectively, you don't at all need to know how to cook, but it surely helps if you can tell jokes well.
Let me explain through an example:
1. User enters the restaurant.
2. User asks waiter for a Sangria.
3. Waiter brings user a Sangria.
4. Waiter is carrying a dish with two oval items 4 and 1/4 inches in diameter.
5. User asks waiter what is in the dish.
6. Waiter replies the dish is made of testes from a bull killed in a corrida.
7. User attempts to order an instance of this dish.
8. Waiter rejects the order explaining that only a single instance of the dish per day
is available.
9. Waiter offers to place a similar order to be fulfilled the next day.
10. User places the order of this dish for the next day.
11. User finishes his Sangria.
12. User asks the waiter for a check.
13. Waiter issues user a bill of 5.75 Euros for the rendered serves.
14. User gives waiter 6 Euros in cash: 5.75 Euros for his Sangria and leaves
0.25 Euros as tip for the waiter.
15. Waiter takes the cash and greets the user with a smile.
16. User leaves the restaurant.
17. 24 hours pass.
18. User enters the restaurant.
19. User demands delivery of his order from the waiter.
20. Waiter delivers the order.
21. User bites the dish 3 times. The dish tastes very well.
22. User visually examines the dish. The dish consists of two oval items
2 and 3/4 of an inch in diameter.
23. User waves his hand in waiter's direction. Waiter comes by.
24. User demands an explanation why dimensions of the fulfilled order do not match
dimensions of the previously displayed instance. Waiter explains that sometimes
the bull wins the fight.
25. User stops eating.
26. User asks for a check.
27. Waiter issues user a bill of 15.55 Euros for the rendered serves.
28. User gives waiter 15.55 Euros in cash.
29. Waiter takes the cash and leaves without a word.
30. User leaves the restaurant.
Now please answer these questions:
You get 5 points for answering positively to each of the first three questions. You get extra 20 points if you couldn't even provide an answer to the fourth question.
If you got more than 10 points, your brain seems to have been trained to think of the world in terms of detailed test plans. You may have a few things to learn here…
If you got less than 10 points, some of this may seem obvious, but hopefully will still provide some useful insights.
In the 30 steps above, I attempted to tell a joke in the form of a typical manual test plan: most navigational steps are described in full detail, while many of important contextual details are left out, or just implied. Domain-specific terminology is used without explanation, mixed with technical terms. Repeated steps are duplicated without any attempt of reuse. But by far the worst offense is that the key elements of the feature are buried in a sea of irrelevant implementation details.
OK, you say, but test plans are used by test people and only test people, so they'd better explain all the details of the feature, otherwise, how can anyone verify that the system works as designed?
Well, that's exactly the problem with test plans as we know them. They are indeed the most detailed specification of the system, but because they are so verbose, and frankly: boring, they are used only by testers and avoided at all cost by all other stakeholders. And because they specify all the details of the implementation, they can be completed only after the implementation has been finalized. Given enough time (which is a rare event) developers may review the test plan once, but no stakeholders other than testers will even dream of maintaining the test plan in its verbose form to keep it up-to-date as the behavior of the system evolves.
Instead, virtually each stakeholder typically writes and sometimes attempts to maintain their own specifications of their view of the system, which inevitably end up being mutually inconsistent, as well as obsolete. As a consequence, communication between the stakeholders suffers and misunderstandings multiply. How often has it happened that a sales person has sold to a customer a product with one or more features that, once the product actually shipped were nowhere to be found?
So, how can cucumber and jokes rectify this dysfunctional mess that the industry has brought itself in? Cucumber's premise is that both new and existing features of a system (i.e., system's behavior) can be described in a single specification with just enough details to make the behavior easily understood by all stakeholders, from end users through sales people, to executive sponsors, and thus enable effective communication of all stakeholders as they collaborate to define and iteratively evolve the system's behavior. And the jokes? Well, they are a form of communication that excels in emphasizing the punch-line, just like the system specifications should excel in emphasizing the system's value proposition.
Let's bring this all together by telling the joke above using Gherkin language and emphasizing the punch-line:
Scenario: American tourist in Spain
Given an American tourist in a restaurant in Spain
And a waiter carrying a peculiar looking dish
When American asks the waiter about the dish
Then waiter replies: "Señor, those are the balls of the bull that was
killed in this morning's corrida. A real treat!"
And American says: "I have to try it! Please bring me one portion."
And waiter replies: "I'm sorry señor, but there's only a single bull fight
each morning. But if you want, I can make a reservation in your name
for tomorrow"
When the American shows up next day
And the waiter brings him the dish
Then American eats a few pieces and takes a closer look at the dish
And calls the waiter and asks: "This dish is really tasty, but I wonder
how come the portion today is much smaller than yesterday?"
And the waiter responds: "Well, señor, sometimes the bull wins..."
Let's see what changed: I've gotten rid of pretty much all the unnecessary details (e.g., the size of the ovals in the dish, the ordering procedure, etc.). I ensured, however, that context important for the punch-line is clear (e.g., that the joke is about American tourist in Spain, someone not acquainted with a local culture). I've kept domain specific terminology (corrida), but ensured the scenario can be understood even by a reader not fully acquainted with it: the story mentions the bull being killed in it, thus the reader can easily figure out it's a spanish word for "bull fight". All this made the it possible to tell the joke in shorter time and thus keep the interest of the listener all the way until the punch line.
Finally, I've added some keywords: "Scenario", "Given", "When", "Then" and "And". Obviously, these didn't come from the joke-telling tradition, so they must be part of Cucumber's Gherkin language. Indeed, they do make the scenario a bit drier than a well-written, free-form prose, but they also make the scenario executable through a series of transformations. It's worth noting that there are two iterations of when-then steps in this scenario: the first When builds the story to a mini-culmination (unveiling of mysterious dish) indicated by Then steps, while the second series of When steps builds up the rest of the joke to the second culmination in the second series of Then steps. If in doubt when to use 'When' vs. 'Then', remember that the latter should contain the actual punch-line of the joke, in other words, 'Then' steps must show the value provided by the scenario. If you can not think of a logical 'Then' step in your scenario, something is obviously wrong: either your scenario doesn't provide any value, or perhaps it's not quite complete. For example, imagine the effect it would have on the reader if the scenario above stopped just before second series of 'Then' steps!
In summary, effective communication between stakeholders requires careful balance between discerning important details and abstraction of unimportant ones. Thinking of scenarios as analogous to jokes where punch-line is replaced by business value provided by the scenario helps achieve this balance: everything that can be left out without jeopardizing the punch-line can and should be left out. Or in words of Josh Bloch: "When in doubt, leave it out!"
I hope you find this analogy useful in your practice. Feel free to share your comments, or perhaps another joke told in Gherkin?
