Whitepapers: Successful Project with Behavior-Driven Development
By Belatrix Software | Topics: Software Development
Use Behavior-Driven Development To Make Your Software Development Project More Successful
BDD Drives Quality And Effectiveness In Agile Engagements
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.
Development Teams Face An Assortment Of Challenges
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:
- Quickly understand and adopt new technologies. Your company’s technical management is under tremendous pressure to meet deadlines and releases, and make teams more efficient. But at the same time they need to research, understand, and quickly adopt new available technologies. Sounds easy? Definitely not.
- Various communication hurdles challenge development, QA, and POs. When working with separate teams that perform development on one side and quality assurance (QA) on the other, unclear requirements immediately become a problem. Sometimes the requirements are well expressed, but each team has developed their own internal language, making communication ineffective. At other times non-technical roles such as product owners (POs) and business analysts, define the requirements, creating further challenges in understanding exactly what is required.
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.
The Evolution From Waterfall To Agile Behavior Driven Methodologies
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:
- Higher priority requirements delivered first. One of the key principles of Agile is prioritizing the requirements (in Scrum this is the product backlog). Stakeholders see faster ROI because higher priority requirements are delivered first.
- Frequent delivery. Delivering with more frequency provides several benefits.One of the most important is that stakeholders receive a working product with new features at the end of each sprint, compared with Waterfall projects where it happens at the end of the project cycle.The more frequent the product is delivered, the sooner stakeholders can provide feedback.
- Rapidly adapt to change. Closely related to the higher frequency of delivery, Agile methodologies enable frequent change. The sooner feedback is given, the faster the team can react and adapt to change. And what if the delivered product doesn´t meet client needs? Clearly it is preferable to realize this after 2 or 3 weeks than spending a year working on the wrong product.
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 Offers New Ways Of Doing Things
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:
- Create a common language. The communication barrier should be removed by specifying in a language understood by everyone. In other words there is a common language developed in collaboration by product owners and the team.
- Clear specifications. Specifications must express clearly what the system must do in order for it to be acceptable for the client. To accomplish this goal, specifications consist of a series of scenarios that are easy to read. Also, these scenarios should be written as examples to make them easier to test.
- Automate. Closely related to the previous point, the resulting scenarios should be automatable.
- User acceptance tests from the very start. By implementing a development process like the one described, user acceptance tests (UAT) take place at the very beginning, even before starting any coding activity. After this essential activity, everyone involved knows what is expected from the software.
Behavior Driven Development Has Numerous Benefits Over Agile
There are 5 key benefits that BDD provides:
- Living Documentation. Specifications reside in plain text files, where every desired system behavior is expressed in a series of scenarios. Those scenarios consist of several steps written in a ubiquitous language understood not only by stakeholders but by everyone in the development team.They are also the base of the automated tests.
As business requirements will change, feature files must reflect those changes and consequently the code behind them needs to evolve to behave as requested. This way feature files work as a documentation source and also as an automated test checklist.
- Better understanding of the software being built. It is a method of getting teams to discuss the acceptance criteria, and ensuring that teams fully understand the business requirements upfront. BDD offers more precise guidance on organizing the conversation between developers, testers and domain experts.Thinking through solutions, before starting to code.
- Reduces communication barriers between domain experts and the team. Using BDD ensures a common language is adopted for discussing new features and removes a lot of the ambiguity that can sometimes creep into user stories or product backlog items (PBIs). The ubiquitous language is usable and understandable not only by the domain experts, but by all team members. This goes a long way in reducing the complexity in the domain and making the barrier-to-entry much lower for new members.
- Encourages better quality software. As team members collaborate to discuss and write specifications, they may realize new possible scenarios they have not thought about before. As result, team members increase their business knowledge while providing higher quality software.
- Lowers the percentage of failed tickets during the sprint. Helped by improved communication and greater collaboration, there should be a significantly lower percentage of failed tickets during the sprint. In the case study outlined later in this report, the percentage of tickets that went to failed QA status during one engagement at Belatrix went from 30% to 2%.
First Hand Experience Of BDD With A Global Risk Advisory Firm
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:
- Communication. Backlog items written in a free-style business language were hard to understand, mostly for less experienced team members.
- Collaboration. There were people with great technical skills but less experienced in business. If they knew the business better they could have contributed more.
- Quality issues. While there was a slight reduction in failed QA issues, it still remained higher than expected or desired.
- Regression analysis. Regression results were available for review the day after affecting the repository, taking one more day to be sure the changes met expectations. But still the successful execution of regression tests, did not guarantee the software behaved as expected.
- Requirements tracking. It was almost impossible to know when a change was requested, who asked for it, who made it, what changed, and what other areas were impacted.
- Heterogeneous knowledge distribution. Some team members had significant business understanding, but it was difficult for them to share this with other team members. Meanwhile new team members found the business rules difficult to learn by themselves
How BDD Helped Solve These Issues
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.
- Issue Tracker. This stage usually takes place in an issue tracker, where the team works in collaboration to write user stories in Gherkin. Based on this they come up with a series of scenarios that can be automated.
Gherkin based scenarios are not only easier to read and understand by everyone in the team but they also serve as the starting point for automated tests.
- Failing scenario. The development team ports the scenarios to the development IDE. As the code base of the client was .NET based, SpecFlow was chosen as the BDD tool.
Each scenario consists of a set of steps (one per line), which state what is going to be tested in order to consider whether the system behavior is acceptable for the user.
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.
- Coding phase or implementation. Now it’s time to start the implementation phase. Developers follow the TDD development process to complete it.
For each implementation method they code, they made use of the Red-Green-Refactor pattern. This means doing the following:
- Write a unit test that fails.
- Write the code that makes this test pass.
- Refactor as needed.
- Passing scenario. After finishing the implementation phase, acceptance tests can be run again to verify they pass. Arriving at this point means that a functionality increment has been reached and the underlying system accomplished the user’s expectations.
- Refactor A refactor phase can also be completed to clean up and ensure acceptance tests are maintained. Once the refactor is finished, changes can be committed to the repository. In addition, as the team comes up with new scenarios, these can be posted in the issue tracker as new tickets.
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.
BDD Evolved Out Of Agile And Helps Solves Communication Challenges
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.