Behaviour Driven Development starts with collaboration, not automation
Behaviour Driven Development (BDD) is an agile approach to delivering software. It promotes communication and collaboration between software development teams and stakeholders in order to create a shared understanding of business requirements. To achieve this, BDD uses human-readable specifications of business requirements to guide development and produce living documentation.
This article will explain how to overcome common misunderstandings of BDD in order to deliver quality features, contribute to the Return On Investment (ROI) and reduce defects as well as cycle time.
Firstly, we will provide an overview of some common misconceptions and then we will deep dive into the three core practices: discovery, formulation and automation.
BDD is a tool for test automation 🚫
A common misunderstanding between Developers, Testers and Product Owners is that BDD is a tool for test automation, however, when teams claim to be doing BDD this isn’t usually the case. In most cases, they are automating scenarios in end-to-end UI tests, after the code has been implemented. These scenarios do not need to be UI driven, as the last thing you develop is the UI. Fundamentally, it is essential to first focus on behaviours, rather than how to test behaviours.
BDD is a testing method 🚫
As tests are a visible output of BDD, it is often mistaken with the test process. The tests reflect the shared understanding of the business requirements and behaviours of the application, which is achieved through BDD.
BDD is only done by testers 🚫
It is not reliable to have only one team member that creates automated tests as this can lead to errors and misunderstandings. BDD is about communication and collaboration, not just test automation. Historically testers have been responsible for quality assurance, but in the “shift-left” testing movement the entire team is responsible for quality.
Discovery, Formulation and Automation
Discovery (“What it could do”) — creates a shared understanding of the requirements through collaboration, typically achieved through a structured conversation centred on rules and examples.
Importantly, BDD starts before any code or tests have been written, with the discovery phase. Software development requirements can be vague and unclear so to combat this BDD promotes having discovery workshops with structured conversations centred around rules and examples. This increases the understanding of requirements, such as features, stories or business rules which ensures that the whole team and client are on the same page when preventing defects, reducing cycle time and contributing to the ROI.
Formulation (“What it should do”) — examples of system behaviour are documented using business terminology.
However, only having conversations around requirements is not enough to thoroughly understand a feature. In order for software development teams to fully understand the clients requirements, you can use examples. Example mapping is an effective way to truly understand the client’s needs. It is achieved by using real world examples to help communicate the behaviours of the system, so the client’s needs are more relatable. Using a “QA mindset” leads to discussion around edge-cases and exceptional circumstances to combat unknowns. At the end of formulation, you should have user stories with examples written in an ubiquitous language. This goes hand-in-hand with Domain Driven Design and ensures both business and technical people use the same terminology, all the way down to the code.
Automation (“What it actually does”) — the documentation is automated, creating living documentation that verifies the system’s behaviour.
As Bertrand Meyer said “incorrect documentation is often worse than no documentation”. Misinformation can result in drawing the wrong conclusions and wasted time due to the rework that is needed. Following formulation, you can use your executable specification to steer development. Before a user story is started the Tester, Developer and Business Analyst, also known as the “three amigos”, meet to discuss the user story. It is beneficial to have three individuals with different viewpoints to discuss any potential issues before any code has been written. Similar to Test Driven Development (TDD), you need to create a test for a scenario, the test will fail if you have not implemented the described behaviour yet. The scenario is implemented in the code and as they are concise and well defined, it helps the Developers stay focused on the given scenario.
The living documentation is reflected in the code, which encompasses the team’s shared understanding and evolving ideas. Living documentation can help to increase domain knowledge for new starters or people outside the team. It can be outputted in an easily readable format for stakeholders who may be non-technical.
Considerations 💭
Even the best development approaches have their drawbacks and require careful consideration, BDD is no exception.
Agility in mind
BDD is unsuitable in a waterfall environment but is more suitable in an agile environment. In a waterfall environment, testing begins once the development work has finished. This leads to misunderstandings, missing functionality and gaps in requirements. This linear, structured, approach doesn’t empower change or amendments to the code until the testing phase has finished. Testing feedback cycles can range from a day, weeks or even months. More than likely defects will be found. In the waterfall approach, developers or stakeholders have less or no visibility of tests. Aslak Hellesøy, the creator of Cucumber, discourages using BDD with a waterfall approach, stating they would only use it in an agile project as specifications are living documentation. Aslak believes you can not come up with this up front. To summarise, using the waterfall methodology takes more time and uses more resources, therefore the costs are higher.
Stick to the business narrative
Another common pitfall is utilising BDD for exhaustive testing, you do not need to automate everything. Using Seb Rose’s blog post on ‘Specifying relative time periods in feature files’ as an example. Looking at the ‘Calculating a month’ section, Seb advises against exhaustive scenarios as they are more like test cases than business specifications. Structuring your living documentation is important, as Rose details that just by calculating a month doesn’t relate to the narrative flow. Calculating a month is a specific detail of the scenario therefore this could be considered as a programmer test. BDD is not about automation or testing tools, it is an entire team approach, it should not only be down to Testers or Developers. To summarise, you do need to aim for exhaustive coverage when writing scenarios, instead you should think of scenarios as vehicles for regression tests.
Summary
In the current environment, writing robust code is not enough, you must also provide well-written documentation. It is important to have buy-in from your organisation as living documentation can become an asset to your team, enabling confidence to rapidly make changes to the system. The main benefits of BDD are to fully understand client requirements based on real world examples, increase communication, shorten feedback loops, prevent defects, reduce cycle time and contribute towards the ROI. Combined with exploratory testing, BDD ensures testing is carried out at the right levels efficiently.
Further reading:
Book recommendations:
Here at Just Eat Takeaway.com teams have autonomy, especially around working practices. Our ethos is you build it, you own it. With over 98 million active users across 25 countries, testing is essential.
Just Eat Takeaway.com is hiring! Want to come work with us? Apply today.
