Within the Agile community, Cucumber has become a widely-used framework for test automation. It can be a great help when used for its primary purpose: namely, helping to build a ubiquitous language for your business and sharing reliable documentation easily understood by everyone from your Product Owner to your customer. That’s why you'll often hear users say that Cucumber is essentially a collaborative tool: to really get the most out of it, everyone on the team should share the responsibility for creating system documentation. 

Unfortunately, however, it's not unusual to find Agile teams using Cucumber solely to automate their tests after implementation is already complete, in a process similar to the following (thanks for this, Matt Wynne!):

If this is how your team is using Cucumber, the unfortunate truth is that you're doing it wrong. Actually, you don't need Cucumber at all in this process. On the other hand, if you want to enjoy the plethora of benefits it can provide, you should start by using it at the very beginning of your iteration, creating your feature files prior to beginning development and - once again - involving the whole team in the process. If everyone participates in writing the feature files, everyone will subsequently be able to read and understand them. 

Not sure how to get started?

One interesting and helpful technique is called Example Mapping. Essentially, Example Mapping suggests holding a quick meeting (no longer than 25 minutes) to discuss a story before development begins. The meeting can be held in a Three Amigos format to ensure that different opinions and perspectives are presented for discussion. 

For this meeting you should use colored sticky notes representing various elements at play. A yellow sticker represents the story under discussion and should have the story summary written on it. Blue sticky notes will each denote one rule or acceptance criteria for the story. Next come the green sticky notes, and with them, the purpose of this meeting. The meeting goal is to describe the rules by adding green stickies with real examples that represent them. It's not important to define the whole example in a given/when/then format - this can be left for later. Instead, the goal is to engage the team to think together about different scenarios and develop a common understanding of how the system should behave in each particular case. All that's necessary for this purpose is to write a descriptive title for the example and ensure each member of the team shares the same understanding of what this example means. When the group decides there are enough examples to represent the rule under discussion, move on to the next rule. 

During the meeting, questions will inevitably arise about how the system should behave in particular examples. If the team is not sure abut the answer, write the question on a red sticky note and move on. When the meeting time is up, the team can quickly vote to decide whether or not the story is ready to be developed. If it's not ready yet, schedule another meeting to finish the story mapping. This way, you'll avoid long and boring meetings in favor of short, productive meetings that stimulate team communication. As with any project undertaking, you may need to appoint one person to drive the meeting and keep the team focused if this becomes a challenge. 

Stay alert for red flags. If a rule has too many examples, for instance, this could suggest that it's too complex and should be split into separate rules. The same logic applies to the story - if you find that it has too many rules, consider breaking it down into multiples. And of course, if there are too many red stickers, it may mean thta the team has more to learn about the story before undertaking its development.

After the meeting, the examples generated will naturally drive the story development and will evolve into your feature file scenarios. The whole team will share a common understanding of the story, and the automated tests will simply confirm that the system behaves as expected. In this model, Cucumber becomes far more useful as a collaborative tool for the entire team.

Excited to give example mapping a try? If you have any questions, considerations or want to share your experience with example mapping or any other BDD techniques, please bring them up in the comments!

References:

https://cucumber.io/blog

http://lisacrispin.com/2016/06/02/experiment-example-mapping/

http://blog.xebia.com/example-mapping-steering-the-conversation/

http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/

https://speakerdeck.com/mattwynne/rules-vs-examples-bddx-london-2014

https://speakerdeck.com/mattwynne

http://blog.avenuecode.com/specification-by-example