Everyone wants to build a bug-free app. Everyone wants to be Agile in their project planning. Everyone wants to have code that compiles without error. Everyone wants their code tested using a combination of solid automation tests and rigorous manual testing. Everyone wants their code to show no regressions. Everyone wants this all done quickly.
And there’s no problem in wanting these things (ideally anyway), but the problem lies in everyone also wanting to do these things their way. How to write user stories, when sprints should end, when QA should be brought in to test — different Agile teams have different ideas of what a development life cycle looks like. This can lead to headaches and ultimately an application that falls short of you, or worse, your customer’s expectations. At Modus Create, we’ve found it’s best to use a development strategy that is consistent and outlined from start to finish; time and time again we find that our strategy lines up with the core concepts of Behavior Driven Development (BDD).
What is BDD?
To better understand what BDD is, you need to first understand the concepts behind Test Driven Development (TDD). TDD is a development strategy that assumes two things: one, when building out an application, each development cycle is short and two, tests for an application’s desired functionality are written first and fail until developers write the code to satisfy them. In short, TDD emphasizes tests that dictate code and not the other way around.
BDD goes beyond TDD and aims to bridge the gap between the development team and owner of the application. While still writing tests first, BDD encourages testing behavior rather than units of implementation. This allows for tests to be written at a higher level and therefore are more understandable by everyone involved on the project. This raises an interesting point. While TDD is often grouped exclusively into the QA or development cycles, BDD transcends that bubble and can be implemented into essentially every part of your project timeline. In fact, BDD’s nature encourages it. To illustrate, let’s use an example.
Scenario
A customer approaches your company asking you to build out an application to suit their business needs. As your team and the customer begin to scope out the work, they bring a list of desired features and functionality to implement into their application. One of those features is a user login form. How does BDD approach this? And when does BDD come into play? The answer to the latter is square one — your Project Manager and customer.
BDD & Project Management
As we talked about before, BDD is not just a development strategy for QA, but for the whole team. It starts with Project Managers sitting down with the customer and defining the behaviors of the features they want in their application. BDD follows a very specific format for defining behaviors. It looks like this:
AS A USER I want to do something
TO ENSURE my feature is behaving the way I desire
GIVEN something has already happened
WHEN I do something new
AND/OR/BUT I do something else
THEN I should expect a certain outcome
This writing format is called Domain Specific Language (DSL) and we’ll explain why this is important later on. The key thing to recognize right now is that BDD helps accomplish a few things:
- It gets the customer more involved. Instead of making assumptions about what the customer wants, BDD involves the customer in writing down ‘stories’ or descriptions of behaviors and their acceptance criteria. This gives the customer confidence in knowing what and how something will be built.
- It clearly defines desired behaviors. Having user stories and acceptance criteria puts the customer and PM in sync with what the desired behavior of the feature should be. This gives the PM confidence to provide their team with step by step instructions on what to build.
Let’s take that user login feature and translate it into a user story using BDD:
AS A USER I want to login to my application
SO THAT I can see my user dashboard
GIVEN I am using the application
WHEN I login to the app with valid credentials
THEN I am signed in successfully
AND I can now view my user dashboard
The login feature is now a user story with its behavior defined and acceptance criteria provided. In traditional TDD, our steps would include more references to UI features such as text displayed on the current page and links or buttons to click on. BDD however, only cares about the behavior of the feature and leaves implementation up to the developers and designers when their work begins. The story is now ready to be passed to our Quality Assurance Team, who have a great foundation in which they can begin writing tests.
BDD & Quality Assurance
The role that BDD plays in your Quality Assurance team is two-fold. First, and most simply, you now have clear acceptance criteria that your tests should pass against, thanks to the user stories created by your PM and the customer. No more time lost asking customers for clarification on how a feature should function. Also, less time will be spent arguing with the customer about what was implemented versus what they thought they were getting. This is extremely important because it not only gives confidence to your QA team that they are writing meaningful tests, but it holds the customer accountable for the clarity of their user stories.
Secondly, having user stories formatted this way makes it very easy for your QA team to translate those stories into automated tests. Earlier we mentioned that the format we’re writing in is called Domain Specific Language (DSL). Because we formatted our stories this way, we can use DSL languages like Cucumber’s Gherkin language. This utilizes lower level coding languages like Ruby and Javascript, to translate our plain English test steps into executable step definitions. Let’s look at a quick example using our login feature. Something like:
(Cucumber) Given I am using the application
Can be translated into code that looks like this:
(Ruby and Watir-webdriver)
Given(/^I am using the application$/) do
@browser.goto(http://coolapp.com)
end
Understanding the code isn’t important at this point. What is important is that the code is written in plain text that is easy to read, using the same steps your PMs and the customer wrote before QA even began working! Having tests that are easily readable allows for project-wide understanding of where and why tests are passing or failing. This helps keeps the project moving and will prevent roadblocks over the course of your project’s life cycle.
All this is to say, BDD’s value to your QA team lies in its requirement to include QA in the project from the very beginning. Time and time again, QA is treated as a last minute resource, either being brought in at the end of development or forgone all together. By having QA be a part of the project from day one, you ensure tests are being written that will dictate the code your developers create and not the other way around. Speaking of developers, with our user stories mapped into tests for QA, we’re now ready to pass those stories to the development team and begin creating the application!
BDD & Development
From here on out, BDD will pave the way for your development team. Because the user stories have been written, and the tests for those stories have been created, your development team now has clear definitions for what to build with explicit acceptance criteria in the form of executable code. This allows them to focus solely on writing code and implementing features for the customer. Better yet, because tests are in place, the developers can run those tests (which will fail at first), and then write code to pass each step until the entire test passes. This concept is at the core of TDD, and in turn, the heart of BDD. It ensures stronger code and gives confidence not only to your developers as they work, but confidence to the customer as the project becomes more complex.
When developers are done with the features at hand and have run their code against the tests in place, they can confidently deploy and know that it will be successful with little to no regression. Even when there is regression, there are tests in place to prevent broken code from being deployed.
Conclusion
With the final code deployed, the customer’s feature has been successfully scoped, tested, and built – all while using Agile and Behavior Driven Development methods. As you begin to use BDD in more of your projects, you will not only begin writing stories and building features faster, you will come away with better software that is properly scoped and confidently tested. BDD is much more than just a development strategy. It’s a restructured way of how to look at Agile software development. Has BDD helped make your project successful? Have questions about how to implement BDD into your team’s stack? Let us know in the comments or reach out to me directly!
