BDD (Behavior Driven Development) is a complete framework for Agile Software Development. It includes 3 main phases: Discovery, Formulation and Automation. When used correctly, BDD can supercharge your Agile processes – by bringing clarity to requirements and bringing in a shift-left, DevOps culture to the organization.
A lot of people think about BDD (Behavior Driven Development) as a Testing or Automation methodology. In fact, it’s not – what BDD brings to the table is a lot more than just Test Automation. BDD is essentially a Agile implementation manifesto – providing frameworks, tools and methodologies on what to do during an Agile Cycle.
Usually I like begin my articles by talking about the background of the subject, what it means to use it for the first time, what are the common challenges and pitfalls to avoid etc. However, for this article – I would rather jump into the details of implementing BDD in an organization – and talk about what are the impacts that you might expect. This article is based off of my experience on working for Test Automation, BDD and Agile in multiple organizations over the last few years. Not all of the points made here may be applicable in your organization – but I hope you can take away at least one thing from this reading.
Let’s start by talking about the common problems in any Software team. If I were to take a guess – I would say: more collaboration between Business and Dev teams, releasing code more frequently, automated testing to catch all bugs before release, scope and clarity of requirements etc., would probably be on top of this list.
And the actual results are not too far off. TechBeacon conducted a survey of enterprise Software Delivery and found that whopping 72 percent of the respondents said that they do, either occasionally or frequently, have issues with production release. Most of these respondents want to be able to release Software frequently with no downtime or deployment problems. Another key problem highlighted was the length of the Software release cycle – being anywhere from days to month – while they should be shooting for deploying fixes in hours or minutes.
There are similar surveys which show issues with Software releases and deadlines. Another set of surveys, including this one, points out few problems in Scope and Requirements Management.
These results are indicative of better approach of Software planning and Design – and I propose BDD (Behavior Driven Development) can provide an answer to these problems. Let’s start by breaking down these problems and why they might be occurring in the first place.
Requirements and Scope Management
The first two top answers of this survey are Scope Management and Requirements Management. That basically tells us that there is no clarity on correct process to follow for Software Requirements or Scope planning and management. The current process we follow – look at Business usecases and come up with requirements document or JIRA tickets for the developers to work on. Then we go into a Grooming session where these requirements are clarified – technical inputs are gathered – and more concrete user stories are developed that are ready to be implemented.
However, there are no strict rules on how to break business use-cases into requirements. There are no rules on when to hold the grooming sessions. There are no rules on what constitutes a user-story, or task, or feature or an epic. How do we determine that these user-stories really solve the business use-case? How do we determine what constitutes as an acceptance-criteria for these user-stories? How do we validate that these acceptance criteria are met when developers mark the ticket as “Done”? What is the definition of “Done”?
Again – there are no right or wrong answers here – and teams pick and choose what has worked in the past and implement their own solutions. BDD however, is pretty opinionated in this manner. It provides a strict framework with definite answers to these questions. This phase of BDD is called “Discovery”.
Discovery: BDD for requirements planning
Discovery is the first phase of BDD – where Business Analysts, Product owners, scrum-masters, developers and testers get together to understand, clarify and refine requirements. This is analogous to the Grooming meeting in the Agile cycle. We walk through each requirements and refine them by coming up with concrete examples use-cases for each of these requirements. Thinking about requirements this way results in better understanding of the problem, the motivation for solving this problem and what are the corner cases that need to be addressed/clarified before beginning implementation. The other advantage of thinking this way – through examples – is that we already got a bunch of test-cases that can act as our acceptance criteria.
How often/how-long do we need to run discovery sessions? Again, the answer here is different than traditional Agile. We run the grooming sessions, fairly frequently – and for a shorter duration of time. Usually right after the scrum meeting for 15-25 mins is the right answer for most teams. This way all requirements and priorities are up-to-date, and this does not cause too much disturbance in devs/testers daily work routines.
I talk more about discovery and example mappings on my medium blog – follow me here if you want to learn more about discovery practices, common patterns and pitfalls to avoid.
Acceptance Criteria and Test Automation
Another frequently asked question during discovery is how do we define acceptance criteria? Does acceptance criteria include Test Automation? Would test automation be part of next Sprint cycle? These are great questions – and I wish BDD were opinionated enough to mandate single way of doing these. However – these questions are too team/use-case/business specific and BDD can only provide guidance on how to accomplish this.
The examples that we came up with during a discovery session – act as a precursor to the end-to-end Acceptance testing criteria. Again, whether they are automated or not – is dependent on the team/business use-case, but we should make a full effort to ensure that these examples are at least included in manual plans, and executed during the test-cycle.
Formulation: Refining Ideas into workable user-stories.
The second phase of BDD is Formulation – where individual user-stories are refined for implementation. Some companies consider this as part of discovery meetings, whereas others traditionally treat this as separate meetings – where requirements are discussed and expanded upon. The main difference between this and discovery meetings is the frequency – a formulation meeting is the one that gets run daily after the scrum, whereas discovery meeting is the one that gets run along with grooming session or sprint planning session.
During a formulation meeting – developers/testers are already aware of the requirement and have had time to think over it. They might have additional examples – or questions about each requirement. Or they might have found a better way to address the motivation for the requirements. In any case – there would be continuous, ongoing, iterative refinement to the requirement and its example – and this is done in the formulation meetings.
In essence, if discovery meeting yielded a perfect user-story, with accurate acceptance criteria and scenarios to test, then we won’t need a recurring set of formulation meetings. However, as we know – understanding requirements clearly on the first go is an impossibility – and these formulation meetings act as a set of clarifications to the original discovery meetings.
Automation: Given, When, Then
This brings us to the last of BDD – Automating the examples we had collected during discovery and formulation meetings. Though a lot of people think about BDD as writing Automation Tests using Given, When, Then – this is rarely the case. BDD is a lot more about requirement management, refinement and clarification than test automation. In fact, scenario automation is just a tool for BDD – and an optional step in the BDD Agile Cycle.
I won’t go into depth of BDD Automation as I have done this in several articles and presentations separately. For now, all you need to know about BDD Automation is good for Acceptance Testing and written in terms of Scenarios that are readable by Business and/or Product stakeholders.
We talked about BDD (Behavior Driven Development) as a way to provide complete end-to-end methodologies and tools for running our Agile cycle. BDD as a development practice has been a boost to all the projects I have worked on previously and can heartily endorse BDD as a good choice for any company. Especially larger companies, with complex Software applications would benefit a lot more from BDD practices.
I run day-long courses tailored for your team on BDD basics, adoption and automation. I am a Cucumber Approved Trainer – and this training is certified through cucumber.io. You can contact me through this link to get more details about the training.
We are a Test Automation focused company – and our primary work is to develop robust test automation frameworks. At the same time, Test Automation forms only part of the problem faced by most companies, and BDD provides a complete end-to-end solution for most organizations.