Is Behavior-Driven Development right for your Project?
An approach for Product/Software development that involves the whole team and focuses on the behavior of the user
If you haven’t heard about Behavior-Driven Development (BDD) that’s okay, it’s actually considered fairly recent, being around for just over a decade. More and more large and small development teams are trusting this Agile methodology, even replacing other better-known and established development strategies.
Other software development methodologies tend to put their attention on the product, however, BDD turns and brings the user and how this user behaves into the process before a single line of code has been written.
A brief history of software development methodologies
Consider another popular development methodology such as Waterfall development, in which you encompass your project’s lifecycle into 5 main stages:
- Requirements,
- Design,
- Implementation,
- Verification, and
- Maintenance
These stages are completed in sequential order and each will have hard-defined protagonists: Requirements is lead by the Product Owner, Design will be taken by Creative/Art department, Implementation is when the Development team shows up, Verification marks the introduction of the QA team, and finally, Maintenance will be taken care of by either a different team or a smaller subset of all the previous teams.
Generally, in Waterfall, you want to start each phase only when you have finished the previous step. That is why, ideally, you will invest at least 30%-40% of your project estimates to the first two stages (Requirements and Design), as it’s going be less costly to fix anything that is not working at this phase as opposed to later on during the Implementation or Verification.
Criticisms to the model circle around, at least to the “Pure Waterfall”, in that, however well planned and robust your Requirements and Design are, the premise that each working unit acts independently and hits the “job’s done” button at the end of their stage, means that unpredictability, changes in business goals, disregarded assumptions, are unaccounted for and, you guessed it… it will screw up the whole project.
Other Agile methodologies have evolved from this model, such as Rapid Application (or Software) Development. RAD puts more emphasis on the development and delivery, and often heavily relies on prototypes to drive the engineers' efforts. To be fair, because of its focus on speed, RAD is most commonly associated to project maintenance stages and modified versions of it have attempted to fix the lack of accent in product design.
Sprint-based development, otherwise called Scrum, tries to fill in the gaps between development focusing on delivery and speed and, at the same time, leveraging the involvement of all the members of a team.
The idea is to keep teams small, no more than 10 people, and advance in successive, progressive goals (or Sprints). Now, this approach has the advantage to give the team a path to correct-course on the fly. If the business decides to move in a different direction, it’s fairly easy to adjust the goals from one sprint to the next.
Unfortunately, the intensity of pace from Scrum can affect the burn out of the team. I have met many developers, working under the Scrum system, who end up feeling blocked and exhausted only after a few sprints. Likewise, since the premise of the model is that the “problem” can’t be understood upfront, it must be recognized as the team works on it, giving less thought to the integration of products and new features with the whole ecosystem that these features are going to be released to.
Finally, it’s important to consider the major figure of the Scrum Master. The position of this person plays a big role in the progress of each iteration, requiring to have a significant grasp of the product and of the skills of each of the team members. A bad Scrum Master can prove to be a big liability for a fast-paced, multi-layered project.
So what about Behavior-Driven Development?
BDD confirms the importance of the user and the interaction between this user and the product. These synergies are usually mapped during the development time on Unit Testing, End to End Testing, Usability Testings, and the likes.
Dan North, largely considered the main advocator for BDD, commented on how he came up with the concept, as he came across how developers write these tests:
Then I came across the convention of starting test method names with the word “should.” This sentence template — The class should do something — means you can only define a test for the current class. This keeps you focused. If you find yourself writing a test whose name doesn’t fit this template, it suggests the behaviour may belong elsewhere.
For instance, if we have a component whose goal is to display the price of a car, as in a price calculator, your tests may start with something like:
Price Calculator Test
-The COMPONENT-
SHOULD
add all the price of all the features of the car plus taxes and other fees
AND show the final priceNorth then realized that if the word Test was changed to Behavior, then the baggage that comes with the word “test” and the “false security” that came with it evaporated.
I started using the word “behaviour” in place of “test” in my dealings with TDD and found that not only did it seem to fit but also that a whole category of coaching questions magically dissolved. I now had answers to some of those TDD questions.
TDD here meaning Test-Driven Development. So a test, like the previous for the price calculator, started to look like this:
Price Calculator Behavior
-The COMPONENT-
SHOULD
add all the price of all the features of the car plus taxes and other fees
AND show the final priceWhile, this is not Behavior-Driven Development yet, the shift from “testing” to “behavior” presented the opportunity to bring the user into the mix. At this point, Dan North was only considering the advantages of his model for development, but then he extrapolated these values to the business. So, all the behavior-driven logistics were applied to a consistent vocabulary for analysts, testers, developers, and businesses aimed to eliminate some ambiguity and miscommunication between technical and non-technical people.
During this time, around 2004, Eric Evans’ book “Domain-Driven Design” became a best-seller and North realized that many of the concepts of DDD can be leverage in its core, which he summarizes as:
…modeling a system using a ubiquitous language based on the business domain, so that the business vocabulary permeates right into the codebase.
The traditional way of describing a User Story follows this template:
As a [X]
I want [Y]
so that [Z]In BDD the vocabulary thinks in scenarios, which evolved the template to look more like this:
Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.The scenarios will be created during Specification Workshops or The Three Amigos meeting, described later in this article. Teams should be involved in this process and, no, “estimation meetings” do not count. When you are at a stage of estimating features we are way past the specification phase.
The psychology behind Behavior-Driven Development
With the use of a common domain (language), we already have the advantage of having non-technical team members to be closer to the development phase.
Also, talking about the deliverable itself, in many of the previously discussed Agile methodologies, the emphasis is on the product. And focusing on the final product is generally good. But, the interaction of the user and the product could very well tear apart many of the assumptions made in the early stages of the Requirements.
If there is a feature that could very well be 20% of your product development, it better be a feature that the users will use and take advantage of, at least, 20% of the time. What happens if the user is just not using that feature? Essentially you are driving thousands of dollars towards a need that was never vetted against actual user requirements.
When you are designing your User Stories based on the User, you are adequately letting the User lead the discussion and providing the roadmap for the development of that — actual — need.
An example of Behavior-Driven Development
Dan North proposes the example of the Credit Card. Traditional writing of specs could be written as follows:
+Title: Customer withdraws cash+
As a customer,
I want to withdraw cash from an ATM,
so that I don’t have to wait in line at the bank.This description seems fine, if not light. It can be used to kickstart a developer or a designer but leaves many loose ends and probably can produce unexpected results.
When we shift our thinking to scenarios, we can remodel these specs and add this:
+Scenario 1: Account is in credit+
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returnedIn this example, we chain events using the “And” keyword in a natural way. We can add more scenarios like this:
+Scenario 2: Account is overdrawn past the overdraft limit+
Given the account is overdrawn
And the card is valid
When the customer requests cash
Then ensure a rejection message is displayed
And ensure cash is not dispensed
And ensure the card is returnedThe common language (domain) used here is grained enough for a developer to develop his tests, and subsequentially, his code.
The Three Amigos
One of the main points in favor of Behavior-Driven Development is the involvement of all the team members when creating these scenarios. Stakeholders such as QA, Development, Product Owners engage in the discussion to generate these scenarios that will effectively become the map that will drive the development effort.
This “discovery meeting”, or meetings, will provide the roadmap for the stories to be extended by the Product Owners. Prioritization and validation play a large role in this stage as the scope of the project needs to be framed within a budget and timeline.
This meeting is closely related to Specification by Example, which is a collaborative effort to keep a single source of truth. While these examples will not replace Tests, it will provide a mapping for the acceptance criteria to be expanded.
State of BDD
Jira, Asana, and especially Cucumber all have at least a sort of plugins or documentation on how to adapt BDD into their system. Meaning that you can track your project using Behavior-Driven Development using your favorite Agile Software.
The reality is that the ramp-up of a team to work under a BDD model is not extensive or expensive. A few elements are going to be needed to the very least:
- Domain Experts (otherwise called Subject Matter Experts): each pillar of the development process must have a visible lead that can help to flatten the language used across the teams.
- A clear understanding of the User and the User Needs: the fundamental source of traction is the full knowledge of how the User behaves, this does not mean only the Product Owner but, ideally, all the members of the team.
- Proper recognition of what is a User Story. Dan North defines a User Story in this article. If a Story is not well written it will throw off the whole process upwards. Just to mention a few key rules: the Title should describe an action, the Narrative should include a role, the Event should describe a feature, etc.
- The assertion that Testing is as important as Development.
- Maximize automation. Considering the importance of Testing, we may need to restructure our testing to cover the most use cases and detect any malfunctioning early on.
What’s Next and Further Reading
Learn different ways to expand and leverage your knowledge in code testing:
Further reading:
