By Belatrix Software | Topics: Software Development
Behavior-Driven Development (BDD) is a software development process which evolved out of many established Agile practices. It helps overcome some of the challenges which teams experience with standard Agile approaches. This report outlines the evolution from Waterfall methodologies to Agile, and how BDD can be the next step in this evolution. It provides practical advice about the advantages of using BDD, as well as a case study highlighting the dramatic improvements in quality that using BDD can provide.
In today´s rapidly shifting business and technology environment, development teams struggle to keep up with the increasing assortment of new technologies, as well as rapidly changing scenarios and customer requirements. Specific challenges include:
Clear communication and understanding of requirements represent key elements in project success. These challenges are exacerbated when the teams involved are from different countries and cultures.
Behavior-driven development (BDD) represents a practical solution to these challenges. BDD helps enhance and expand software project team capabilities, reduce communication challenges between technical and business roles, reduce cost, and accelerates time to market. But first, lets examine the evolution from waterfall development methodologies to Agile and BDD.
One of the most common problems with traditional waterfall methodologies is its slow response to change: it simply requires too much time with defining requirements, analysis, design, implementation and testing, to end up with a working product. This results in missed deadlines, obsolete product deliveries, and increased costs.
To address or mitigate these project killers, Agile methodologies deliver working software as quickly as possible by dividing the software building process into small and relatively short iterations or sprints (typically 2 or 3 weeks), and deliver a working product with a functional increments by the end of each iteration. This provides the following benefits:
However despite these advantages of Agile over Waterfall, there can still be challenges. Just because Agile gives teams the chance to adapt and correct in subsequent sprints, it is still something that should be avoided. Spending one iteration delivering something that may not accomplish stakeholder’s expectations is still expensive.
If the software does not do what it is supposed to do, it means there are communication issues to fix. The question is therefore, how can the communication gap between stakeholders and the team be bridged? How can the team better understand what clients need? To answer these questions, let’s look at behavior-driven development.
Behavior-driven development (BDD) is an Agile approach to software development that encourages teams to deliver software by emphasizing interaction between stakeholders. It takes into consideration both business and technical perspectives – and one of the key ways it achieves this is by writing test cases in a language that both technical individuals and non-programmers can understand.
BDD is therefore based on the principles of test-driven development (TDD). The general principles of TDD include object oriented analysis, and design and domain-driven design. In BDD the developer uses this to describe the code (its purpose and benefit) in language that non-technical stakeholders can understand. This helps develop a shared set of tools and processes for software developers and business analysts, enabling better collaboration during software development.
The BDD process can be seen as two related cycles. Even though some authors draw them as concentric cycles, we prefer to show them separately for clarity. The image shows the BDD process and its relation with TDD.
This process assumes the use of tools to support development. Some of these tools could be developed specially for BDD, however they can also be considered a modification of a tool that is currently used for test-driven development (TDD) projects. The tools are used to support automation to the common language that BDD is based on.
In order to minimize or remove misunderstandings between stakeholders and the team, current processes need to be replaced from scratch. This challenge implies several changes:
There are 5 key benefits that BDD provides:
Belatrix implemented BDD in a project with one of the largest risk advisory companies in the world.
The company had distributed Agile teams, each one with 7 to 10 members (developers, testers and product owners), delivering a huge number of changes with each release.
Although requirements lived in an issue tracker, they were written in natural language. It caused some misunderstandings between what the product owner expected the system to do, and what the development team delivered. In addition, testing engineers used their own tools to create automated tests, designed from their understanding of the business rules and requirements.
As a result, there were sometimes up to 3 different perspectives of the same requirement.
The initial measure to mitigate misunderstandings and reduce quality issues, was for the developers and testers to work closer together. To achieve this it was decided to run tests locally on developers´ machines before affecting the code repository.
However, despite this, there were still gaps between the software products requested by product owners and what the development teams were delivering. At this point, the product backlog items were still written in business language. In addition, coding tasks started before the team agreed the acceptance criteria of those items.
As a result, the team was spending time in coding tasks while not having certainty about the correctness of the software to be delivered.
The initiative of executing local tests before affecting the code base was a good starting point. However there were still a number of unsolved problems:
To help solve these challenges, Belatrix decided to implement BDD. The following section walks through an example of implementing BDD, along the BDD process outline.
Because no code has been written yet to specify what to test in each step, running the scenario shows it as pending in the test results.
The development team wrote the necessary code for each testing step. The great news is that developers and testers are all involved in this phase. The more they work collaboratively, the more they can benefit from each other.
Once the all scenarios are ready, the scenario can be run again to see how the test fails.
That’s exactly what is expected, because at this point we have stated what will be tested even though not a single line of implementation code has been written.
Notice that at this point we have defined what we want the system to do and we have created the code that tests that behavior.
At the beginning the team didn’t use BDD and approximately 30% of the tickets failed and were then later fixed during each sprint. As the project moved forward with the BDD implementation, the amount of failed tickets decreased as the team changed the way they wrote the tickets and the acceptance criteria. Currently the percentage is around 2% (see Figure).
This reflects the deep changes in communication which BDD brought about within the team and between stakeholders. By enhancing collaboration and communication, quality significantly improved.
Business stakeholders often face challenges in articulating exactly what they need in language understandable by technical roles. Similarly, technical roles typically focus on how to make things work, and struggle to really understand the business value of the requirement. This is a challenge that every software development team struggles with.
BDD aims to help solve those problems and increase the success rate for software teams by clearly identifying a stakeholder, a business effect, and a business value in each user story. It also describes several scenarios, each with a precondition, trigger and expected outcome, all using a common, team-wide accepted language. The impact of this is increased quality and speed of development – much needed in today´s rapidly changing environment.