Most of us are familiar with user stories. The structure of a user story is typically something like:
As a [type of user], I want to [perform some task] so that I can [achieve some goal].
However, articulating what is required in a natural language is one of the hardest things in software development, since natural language opens the door to many interpretations. I covered more on this in my BDD Unit Testing article. To address this issue, many companies have started using Behavior-Driven Development (BDD) to define their requirements, as you can not only define requirements using natural language but also execute the requirements to check if the requirements been implemented correctly.
In this article, we will look at what BDD scenarios are, how they’re are defined, how you can implement BDD for a user story and acceptance criteria, who writes BDD scenarios, BDD examples—and how you can use NoCodeBDD to automate BDD Scenarios in minutes and without code.
What are BDD scenarios and steps?
BDD scenarios are defined using the Gherkin language, which gives a structure of how BDDs written. Gherkin uses a set of key words to provide this structure and it is available in many natural languages. Though there are many keywords in Gherkin language, the critical ones that define the scenarios are:
And. We will look at these keywords in more detail in the following sections.
The following shows the important BDD keywords—Given, When, Then, And—and explanations for each one:
Given — This is used in a step to explain the pre-condition for your test.
When — This keyword is used in a step to explain the actual behavior you are trying to implement.
Then — This keyword is used in a step to to explain the outcome of your test.
And — And is used when you want to add any additional information for any of the steps
The image below shows how the feature, scenario and steps using the Gherkin format are defined in BDD.
BDD Scenario Example USING GHERKIN FORMAT
Sample BDD Scenario
BDD Scenario: Get alert when account is debited
Given I have logged into my account successfully
And my balance is shown as $100
When I debit $20 into Joe Blog’s account
Then my account balance should be $80
Once the BDD scenarios are defined and steps are written in plain language as shown above, the developer can use these scenarios to implement the solution. The quality assurance (QA) team should take each step and write relevant automation scripts for each step. Using NoCodeBDD this automation can be achieved without any code and in minutes. Let’s look at how automation is done in the next section.
One of the principal benefits of using BDD is that it allows you to automate the scenarios that have been designed. The beauty of it is this: the scenarios defined in plain language are taken and automated. The scenarios that are defined are nothing but a requirement specification for your product, and BDD allows you to execute that requirement specification. If you compare this to a non-BDD process, the scenarios are defined by QA, likely in isolation, and someone has to correlate the scenarios written by QA to the user story to make sure all scenarios are covered. This process is error prone and there is a high probability that what the product owner expects might differ from what the QA has written. This is a significant point, and it’s why I believe BDDs are so powerful.
Though there are many tools such as cucumber available to roll out and automate BDDs, all of them require considerable coding/scripts to automate the scenarios and the teams have to spend quite a bit of time maintaining the code. With NoCodeBDD, the BDD scenarios can be automated in minutes and without having to write any code. The following video shows how you could use NoCodeBDD to automate the scenarios that we derived above.
As you can see, writing BDD is simple and straightforward. All you have to do is write the behavior in natural language using Gherkin, which is as easy as pie. One of the key points of BDD is automation, and as we have seen, with NoCodeBDD automation can be achieved simply, without code. So, at what point in your development life cycle should BDD be considered? Getting this right is quite important.
BDD in the Development Life Cycle
BDD scenarios should be the first process in your development cycle. Writing the requirements as BDD scenarios and at the start of the development process allows the team to discuss all possible scenarios, develop a common understanding, and keep everyone on the same page. This improves the quality and time of delivery significantly, as different team members know exactly what has to be developed/tested up front, without any ambiguities or misinterpretation. By discussing, defining, and agreeing on the scenarios up front, any bugs that might get introduced into the system during the development process—due to misunderstanding of the requirements—are prevented. The following diagram shows the development life cycle using BDD:
As soon as the team is ready to start development, the team—mainly the three amigos—should collaborate and derive the scenarios. All team members involved in developing the story should be involved in the collaboration process. For example, if the story requires UX-related tasks, then the UX engineer should be involved. Many agile teams do some sort of collaboration; however, I have seen these collaborations fail to be effective, and in many projects teams collaborate simply for the sake of collaborating, as it were. Using a methodology would help the team to collaborate through a good, structured process. I have personally used a technique called OOPSI, introduced by Jenny Martin and Pete Buckney, and it has made significant difference in applying a structure to the collaboration process, it helps deriving scenarios efficiently, and helps analyze the entire process thoroughly. In the following section, we’ll look at how BDD scenarios can be derived for a given user story and acceptance criteria.
Implementing BDD for a user story
When a collaboration process such as OOPSI is used, the team should always have the outcome (i.e. the business expected result) written, and it should set aside acceptance criteria separately and have it visible through out the process, so the scenarios derived are always mapped back to the outcome—nothing more or nothing less. Let’s look at OOPSI and how it could be used to derive BDD scenarios from a user story.
OOPSI stands for:
O – Outcome
O – Output
P – Process
S – Scenario
I – Input
Outcome: OOPSI always starts with the outcome. This is a critical point, as it emphasizes the importance of focusing on the outcome of delivering the story in other words. Outcomes are nothing but the acceptance criteria. Starting with acceptance criteria and deriving everything else from there keeps the team focused on the outcome the business expects.
Output: The next step in OOPSI is output. The team should discuss and derive the outputs that are required to achieve the outcome. For an example, if the output of the scenario is to send an email or saving something in a database or calling a third-party API, then those should be defined.
Process: Once the outputs are defined, the team discusses the processes required to achieve those outcomes. This is quite helpful for the developers, as it will help them to understand the processes they need to change/develop to achieve the outcome.
Scenario: Once the processes are defined, the team should discuss the different scenarios required to achieve the process. This helps the team discuss all possible scenarios that will affect the outcome. The team along, with Product Owner/BA, also has an opportunity to confirm the scenarios and even remove scenarios that may not be required, or even de-prioritize.
Input: Last but by no means least, is the inputs required to implement these scenarios. The inputs could be anything that is required for the scenario. This allows the team to discuss the different types of inputs required, and prompts the team to have the inputs ready—and sometimes it might even come from a different team or a different member of the team (e.g., the architect).
As you can see, by following OOPSI up front, the team understands the required outputs, the process that needs to be developed or changed, the scenarios they need to handle, and the inputs required to achieve these. And most importantly, all these are geared towards the outcome that the business actually expects. Moreover, because the team discusses all these as a team at the beginning of the process, the entire team is on the same page, which will result in higher quality output and reduces time to market. My blog about How BDD helps your overcome Muri, Mura and Muda explains how rolling out a BDD can improve quality, reduce time to market, and reduce stress on the team.
How do you write a BDD scenario?
During the collaboration process such as OOPSI, it is important for the team to start defining the scenarios and the steps involved to achieve those scenarios. Though the team might have to spend an extra bit of time defining the scenarios and steps, this saves them a huge amount of time through out the development life cycle. As I mentioned above, BDDs are typically written using the Gherkin language. If you are using tools like Cucumber or NoCodeBDD there are 3 distinct parts to BDD: Features, Scenarios, and Steps. The Steps defined are later used by QA to create automation scripts called Step Definitions.
Features define high-level requirements; typically you would define a feature for each user story. Each feature would define multiple scenarios that applies for that feature/user story. And each scenarios would have the steps that are required to achieve that scenario.
During collaboration process, it is important that the team defines the steps for each scenario. This is essential, as it removes any ambiguities the team members might have in correctly implementing the scenario. For brevity’s sake, not all scenarios are given below, but some of them are:
Scenario 1: When Mike transfers money from his account to wife Melinda’s account then Mike’s balance should be deducted
Scenario 2: When Mike transfers money beyond his available balance then the system should not allow him
Once the scenarios and steps are written, the developer takes each of those scenarios and starts implementing a solution. The QA, in parallel, writes test scripts for each of those steps. Following video shows how the BDDs are automated using NoCodeBDD without any code and in minutes
Who writes BDD scenarios?
This question is commonly asked by those new to the process. The short answer is the entire team. Unlike test-driven development (TDD), which is the developer’s responsibility, BDD belongs to the entire team. During the collaboration process, the team—with the input and assurance from the Product Owner or the Business Analyst—derives the scenarios, the QA uses those scenarios to automate, and the developers uses those scenarios to implement the functionality. This is quite an important point, as giving responsibility to a single person reduces the effectiveness of BDD and discourages the team owning the responsibility. By engaging the entire team in the process, all the team members, technical or non-technical, are on the same page and collectively take the responsibility of delivering the right solution.
However, the automation side of BDD should be owned by QA or by the person who doesn’t implement the code. When a product like Cucumber is used, the team requires an engineer to write the scripts that automates the step. Using product like NoCodeBDD eliminates this, and anyone—even those without technical knowledge or coding knowledge—be it a BA or a manual tester, can automate BDD without any code and in minutes.
The beauty of BDD, as well as its biggest biggest advantage, is that you can define your requirements as different scenarios in natural language, and execute them to validate whether the implemented solution is as per the requirement. Implemented correctly, BDD reduces ambiguities in requirements, improves quality, and reduces cost.
Using NoCodeBDD, rolling out BDD and automating development is easier than ever before. The basic version of NoCodeBDD is free, and you can download it from www.nocodebdd.com/download and implement and automate BDDs in minutes.
Jerome Josephraj is the Founder and CTO of NoCodeBDD. He has more than 20 years of experience in Software Development and have been rolling out Behavior Driven Development for large projects in United Kingdom. He has a strong Java Development Background and have been working as a Technical Consultant. In one of his recent large enterprise projects, he has successfully rolled out Behavior Driven Development consisting of more than 1000 scenarios. He was also the Founder of http://www.campusinteraction.com, a student analytics portal, which was later bought by Preludesys. Based on the previous start-up experience and a strong Behavior Driven Development experience, he founded NoCodeBDD to improve efficiency of rolling out Behavior Driven Development by 10x.