How a Cucumber Helps Your Three Amigos Speak Pidgin

Mobile app development needs to move fast, which means using Agile and Agile user stories. 

Agile user stories typically follow the following format: As a __, I want to __, so that __.

User stories are typically written by the Product Owner. In many cases, developers and QA resources are specifically excluded from this process. But when all three aren’t involved in the creation of the user stories, you risk some serious problems:

1. The stories could be too sparse: “I want to deposit a check”. This tells us nothing of HOW a check is deposited. It assumes we know all of the things we are actually looking to build.
2. The stories could be too detailed: “I want to log in to the expense reporting app to dispute the incorrect figure on my last paycheck.”
3. The stories could be technically impossible: “I want to use Siri do my taxes.” Siri does not yet support third-party apps in this manner.

Poorly articulated user stories can lead you down rabbit hole of false starts and leave you with huge schedule issues and cost overruns. 

Enter The Three Amigos

Part of the Cucumbering process is the essential collaboration between the Three Amigos: the Product Owner or BA, the developer and the QA lead. Unlike approaches where the Product Owner owns the requirements process, the Three Amigos create the requirements collaboratively.

The three work together to build well-defined user stories (known as Cucumber Scenarios), and each Amigo adds their unique perspective to help define and elaborate on features.

A Product Owner may say I need “an in-store payment system that accepts payment for all major credit cards.” QA may say, “Okay, so what are those major credit cards and are debit cards included?” The developer may ask, “And do we need to require signature authorization for credit cards, and four-digit pins for debit cards?”

The Three Amigos help rapidly develop well-balanced, articulate and most importantly – technically feasible requirements.

Doin’ the Pidgin

Even the best and clearest user stories are not written in a language that is clear enough for development and QA to test accurately.

Development must take those stories and translate them into programmer speak. Then QA must interpret both the user stories and programmer speak into a testing lexicon.

As each group evolves its own language of terms, phrases and understandings diverge. Is it an “account”, “login”, or “auth credentials”? The Product Owner uses “account”, looks at the code and sees “login”, while QA is testing for “auth credentials”. Speaking separate languages creates serious risks and communication issues.

More frustrating, user stories are not designed to be machine-readable and testable. This means developers need to write their own unit tests to validate against a user story, while QA needs to write their own separate test cases and scripts as well.

This is why the pidgin (shared language) angle of Cucumber is so amazing. The aim is to create one authoritative language housed within the Cucumber Scenarios that everyone on the team (technical, non-technical and machines) can understand and use.

Cucumber

Cucumber enables everyone to describe and document features so they are understandable to non-technical resources, but still sturdy and clear enough for programmers to develop against. When the Cucumber scenario passes, everyone on the team knows for certain the feature is complete.

The power of Cucumber lies not only in its ability to unite your teams’ testing needs under a common pidgin language, but to automate much of the testing needed for your mobile app.