Introducing Behavior-Driven Development in an Agile Team
Almost one year ago a new distributed and remote agile team was created at DefinedCrowd with the purpose to tacked existent business needs by creating a new microservice. At the beginning the team defined which business case would be solved, how the system architecture should be and how it guarantees the software quality at each delivery to the newly created service.
During the first stage of software development, it is crucial to understand if the service is being built in the right way, and, of course, if it is the right thing being built. The team, therefore, should have a shared understanding about feature requirements. But how would we work collaboratively to discuss the requirements and write the testing scenarios which represent the actual system behavior? To achieve this, the team proposed applying and using the Behavior-Driven Development (BDD) technique in their work process.
What Does Behavior-Driven Development Mean?
Behavior-Driven Development (BDD) is a development process which encourages team collaboration and better communication, focusing on the business problems that need to be solved, getting faster feedback and live documentation to meet system behavior. (Amodeo, 2015)
The keyword is conversation. The conversation before development is the trigger for the team to have a shared understanding of what is the purpose of the new user story and/or if it is necessary to refactor existent code. To clarify the acceptance criteria, the team is invited to illustrate the criteria with some concrete examples. This means writing the scenarios that represent the behavior of the system.
To drive this conversation, it is followed the Gherkin syntax (Figure 1) as the common communication language. Gherkin is technology agnostic, human readable, structured, and keyword based. It provides excellent documentation by transcribing the expected behavior of the system, which can be read and easily understood by all team members and stakeholders. Furthermore, the scenarios written out can be turned into automated tests in the future, which contribute to the creation of living documentation that reflects the true state of the project. Having a single place to keep all this information saves a lot of time that would otherwise be wasted trying to keep documents, tests, and code synchronized.
Gherkin syntax example
Feature: Get user information
As a Project Manager
I want to search by user Id
So that I can get the user information
Scenario: Validate the information for a specific user
Given The Project Manager has access to the service
And An user is created
When The Project Manager requests the information of a specific user
Then The service returns the response 'OK'
And The service returns the user details
| name | phone | address |
| User A | +351 999999999 | Portugal |
This is a practical example of documentation on getting a user information feature. The scenario expresses what to expect from the microservice when the project manager wants to get more information about a specific user. The ‘Given’ statement represents the necessary preconditions to run the test. The ‘When’ represents the action that will be taken. Finally, the ‘Then’ expresses the actual behavior when the action, ‘When’, is taken.
Proposed Steps to Use BDD In A Team’s Process
In theory, BDD and Gherkin seems to have a lot of potential. However, to understand if the ideas behind these two concepts are true, it is necessary to try out in a real case scenario by incorporating it in the team’s agile process. Currently, the team’s agile process includes the following activities (Figure 2):
The proposal is to define the scenarios during refinement ceremonies by using BDD. Therefore, the development process will not change, but will be enhanced with the inclusion of test scenario definitions.
During the Technical Refinement (Figure 3) the team (QA and Devs) has the first contact with User Story requirements. Additionally, to analyze how it would be implemented, the test strategy is also discussed.
When developing a microservice, the testing strategy is focused on two different test levels: unit tests and component tests. For unit test level, the team identifies which individual methods should be covered and the desired coverage percentage. On the other hand, the goal of the component tests is to validate if all microservice pieces are well integrated and working as expected. So, the testing strategy definition for component tests is focused on expressing the functional behaviors by using BDD to define the happy path scenario(s), as shows the example in Gherkin syntax example.
In the next stage, at the Refinement session, where the happy path is already defined, the team starts to write other scenarios (happy or unhappy paths) covering all the acceptance criteria. This is the moment when the test discovery starts to take shape (Figure 4).
After discussing the scenarios, the team agrees that the user story is ready to be implemented.
BDD as a Test-Driven-Conversation
The first outcome of introducing BDD in the team’s process was to engage all the team members in defining the testing strategy for a user story. At the same time, it helped everyone to understand what should be developed or delivered, which ultimately resulted in more effective refinement sessions.
From the first test case written in Gherkin, the way the test was specified as an example, sparked the team’s imagination to see other scenarios that were not considered. Consequently, test and functionality discovery were augmented because it was easy to create variations of previous scenarios.
Nowadays, the team has more than ten features written using the BDD approach. When it is necessary to add an increment to an already existing feature, the amount of work that the team needs to do to automate the increment is noted, which helps to estimate the automation effort. Figure 5 shows the steps already implemented, in white, and the steps that should be implemented, in purple, which helped us to understand the cost of automating this new scenario.
One of the greatest benefits that this process of written BDD scenarios brought to the team was the possibility to visualize how the system behaves before it has been built and to rethink the technical implementation. To give an example, during the scenario definition for a specific feature, the team realized that to perform that action, the service would need to keep extra information that was not considered during the technical discussion. As a result, development and automating test work were readjusted by adding one more precondition.
Challenges of Using BDD
The challenge starts when the team is writing the first scenario. The process of using the Gherkin syntax properly and take advantage of Examples and Scenario Outlines usage, involves a steep learning curve. If someone in the workgroup has knowledge and experience on how to use BDD, it is helpful to have a session with the whole team beforehand to explain what it is, how to use Gherkin syntax, and what is hoped to be achieved with this approach.
Team members decoupling themselves from the specific details of the technical design during the process of writing scenarios for backend component tests is not easy. Although the scenarios are a representation of the actual behavior of the system, it is difficult to avoid some technical words when the system under test in an API.
As the number of features and scenarios increase, it is necessary to refactor the Given/When/Then sentences from time-to-time to maintain the consistency of fluidness and naturalness across all scenarios. To achieve this, we must define guidelines like writing the steps in the third person and as a subject-predicated action phrase.
Key Takeaways
Making use of BDD as a communication tool, the team was able to make more use of Devs, QA, PO and stakeholders inputs. Collaboration and conversion are crucial to achieving success when adopting BDD.
From this experiment, the Refinement session was the best place to introduce this conversation since it is in this phase when the team discovers the feature requirements and what they should be building. Our proposal is to drive this conversation making use of Gherkin syntax and expressing the feature requirements in a common language that can be read and easily understood by all team members.
Besides improving the shared understanding of what should be delivered, the written scenarios bring two more benefits: they serve as live documentation and can be reused when the team automates the tests.
One of the greatest benefits of using this approach is team collaboration in scenario discovery. It facilitates the identification of technical/feature/quality gaps in the system and provides a valuable opportunity to rethink the technical implementation at an early stage.
As with any other tool, it has a steep learning curve that be increase according with the team’s member experience using this methodology. If the team is not familiar with Gherkin syntax, the first Refinement Sessions could be longer. So, it is suggested that, from the adoption phase, to keep the number of User Stories lower. It is helpful if any team member with experience using BDD, and it should be the driver to kick-off this initiative by writing the happy path scenarios before refinement discussions.
Even with the increasing number of challenges that the adoption of BDD brought to the team, it also gave a lot of great value to every team member professional careers and an increasing sense of quality to the overall result of the deliveries.
