Behavior Driven Development Principles

Clear Communications

As pointed out above, requirements are not always clear between developers and stakeholders – developers could, quite possibly, be from Venus and stakeholders from Mars.  The two groups talk in two completely different languages.  No wonder why there’s so many software failures. (Microsoft reports that over 80% of development project fail, not because of bad development, but because of bad communications or changing expectations over time.)  This is why agile development is on the rise – self-correcting sprints that ensure the realignment of development with business objectives.  So, while agile has helped, what about the 2-4 week sprint that was spent developing something that completely missed the mark when it comes down to the business’s expectations?  Now we have to rip it out and start the story over – wasting those 2-4 weeks.  What if this repeatedly happens?  Furthermore, we all know that its a lot more time consuming to remove a piece of functionality once it has been implemented.  In the end, both, the confidence of the business in developers and the confidence of the developers in the business, is diminished creating a frustrating (and sometimes, hostile) working environment that’s rewarding for neither party.

Therefore, it is important that expectations are communicated clearly and understood by stakeholders and the development team.  There is a need for an ubiquitous language.  For this reason, a language construct has been adopted.  This language is known as Gherkin.  While some of you may know that a gherkin is formally a fruit of the cucumber family, a language format has been constructed to aid us in acceptance testing.

Gherkin

Gherkin serves as an ubiquitous language that is understood by both developers and stakeholders.  Gherkin follows the “G-W-T” format; or, Given-When-Then.  It describes an expected result based on a given scenario and a user’s actions.  There are a ton of quality blog posts that are specific to Gherkin – one here – so I will not spend a lot of time showing examples.  But, from a clear and succinct Gherkin scenario, a User Story can be derived.

Why is the language named after a pickle?  Well, that’s because an acceptance testing framework was written that was also named after a pickle – Cucumber.  Cucumber was originally written for Ruby on Rails (yes, we did, at least, get one good thing from Ruby) and has been ported to other languages since.  The Cucumber framework parses the Gherkin language using Regular Expressions in order to execute our acceptance tests.

One more thing before we get started in implementation…

Living Documentation

How many of us have heard that before?  And, upon hearing it we roll our eyes and think, “Yeah right.”  The truth is, our intentions are good – and we have some fine Business Analysts who have spent large amounts of time to create great documentation – but, in the end, the business gets in a hurry, the development pace increases, time for documentation decreases, and, before we know it, we are a couple of sprints behind (if not more) in documentation.  By the time the project is completed – or at least the current phase – the documentation is nowhere near the resulting product.  When the business asks how long it will take to get the documentation up-to-date, we reply a week or two to which the business responds, “Then, we’ll do it later.”  And, in the back of our minds, we know that simply means, “Never.”

The additional beauty of Gherkin and acceptance testing is that the tests truly become a living document of business requirements.  The scenario’s (features) described in the Gherkin scripts constantly evolve with the development of the application.  For this reason, we can always be sure that our application and the scenarios are in sync.  Furthermore, the tests always hold the development team accountable to the intended outcome.  The development team will never deviate from the stated business objectives unless those objectives change during the development cycle.  Then, of course, the Gherkin scripts change, our code changes and the living documentation changes.

An example scenario is below.  From that scenario, you can see that I have a version/release number, the requirement identifier, the clearly stated objective (scenario) and the Gherkin construct that describes the acceptance test.

My business requirements documents are constructed using the Gherkin language so that both, the business stakeholders and the developers, are on the same page.  If this isn’t the case, then what’s the point of wasting so much time on a BRD?  And, for those of you who also use a Functional Specifications Document, this document now becomes obsolete.  Imagine, one less document in the workflow and a modified BRD that’s actually helpful.  Ahh, happy thoughts.