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. To create a shared understanding of business requirements and behaviours of the application. BDD uses human-readable specifications of business requirements to guide development and produce living documentation.
This blog post covers 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.
First we will look at some common misconceptions. Afterwards, we will dive into the three core practices: discovery, formulation and automation to overcome these misconceptions.
BDD is a tool for test automation 🚫
A common misunderstanding between Developers, Testers and Product Owners is BDD is a tool for test automation. When teams claim to be doing BDD it isn’t always the case, after you take a closer look it turns out they are automating scenarios in end-to-end UI tests, after the code has been implemented. Scenarios do not need to be UI driven the majority of time the UI is the last thing you need to develop. It is essential to 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 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 🚫
Having only one team member that creates automated tests independently can lead to misunderstandings. BDD is about communication and collaboration, not just test automation. Historically testers have been responsible for quality assurance, 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. This happens in the discovery phase. In software development requirements can be vague and unclear. To combat this BDD promotes having discovery workshops with structured conversations centred around rules and examples, it increases the understanding of requirements, such as features, stories or business rules. Ensuring the whole team and client are on the same page can prevent defects, reduce cycle time and contribute to the ROI.
Formulation (“What it should do”) — examples of system behaviour are documented using business terminology.
Significantly, 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 clients 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 potentially losing time due to rework. Following formulation, you can use your executable specification to steer development. Before a user story is started three amigos should meet, usually a Tester, Developer and Business Analyst to discuss the user story. Having three individuals with different viewpoints can avoid issues before any code has been written. Similar to Test Driven Development (TDD), you create a test for a scenario, the test will fail as you have not implemented the described behaviour yet. The scenario is implemented in the code. As scenarios are concise and well defined, this helps the Developers stay focused on the given scenario.
The living documentation is reflected in the code, the documentation encompasses the team’s shared understanding, that is constantly evolving. 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.
Drawbacks
Even the best development approaches have their drawbacks, BDD is no exception. In order for BDD to work effectively, you need buy-in from your organisation and team. BDD is unsuitable in a waterfall environment, instead it is more suitable in an agile environment. Another common pitfall is utilising BDD for exhaustive testing, you do not need to automate everything. Finally, BDD is not about automation or testing tools, it is an entire team approach, it should not only be down to Testers or Developers.
Summary
Today writing robust code is not enough, you must also provide well-written documentation. Importantly, the living documentation will 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:
