Behaviour-driven Development, or BDD, is an Agile software development methodology where developers and testers work together with customer or domain experts to develop code that passes automated tests written using the non-technical language of the business space.
This technique closes the gap between business and technical people and allows a structured discussion with the client that feeds into the features being built. It creates a comprehensive and well-written set of tests that avoid ambiguity and result in working code.
As with other Agile practices, stories in BDD are broken down into small components to facilitate rapid delivery of multiple, small-scale releases of functionality, but in doing so it effectively bridges the gap between the user stories and the written specification.
In BDD the people writing and testing the code have structured conversations with user representatives on the business side, building each story and creating a shared understanding via real-world examples and edges cases to establish how the system is required to behave. Such conversations are an essential part of BDD, as each participant brings a distinct perspective.
This phase is referred to as ‘Discovery.’ BDD has everyone in the same room, working through the stories together, one by one, feeding back and documenting them. There is a risk this process can be seen as onerous by the customer, but the advantages are clear in helping to spot and resolve any missing or ambiguous requirements.
The outcome of the Discovery phase is effectively a system specification, comprehensive enough to be used to construct test suites in the ‘Formulation’ phase, to be run against each code iteration in the ‘Automation’ phase. Importantly, the specification is also designed to be understandable to those on the business side by minimising the use of technical language.
This process of Discovery, Formulation and Automation helps prevent a developer taking a story through to implementation independently, potentially having missed, or misunderstood, required functions, or having tested them inadequately.
BDD employs such tools as Cucumber, in JavaScript, or SpecFlow, in the .NET environment, that use the phrases of the user story (“as a…,” “I want…” and “so that…”) and acceptance criteria (“given…,” “when…” and “then…”) to help build the automated tests.
One example of BDD in practice at Headforwards was where BDD enabled automated testing to be carried out against user stories in a project where the client did not think automated testing would be possible.
The project was to provide functionality for a healthcare provider, where different combinations of drugs were being fed into a human-driven process with lookups to resolve the price. The Headforwards team applied the BDD approach, starting with simple examples and then expanding to cover additional scenarios until a comprehensive set of automated tests had been constructed, against which releases can be tested comprehensively and therefore avoid regression.
Considering IT as a support function is an antiquated concept. And having a separate IT strategy neglects to consider how significant the advancement of technology has been in recent years. How should business leaders think about IT strategy? Our Lead Advisory Partner shares his thoughts in this article.
Our work with Cornwall Council started by looking at how the department could change its behaviours to better support Agile working processes.
In this article, experienced QA tester at Headforwards, Gowri Thota, shares his thoughts on successful testing regimes.
Headforwards™ is a Registered Trade Mark of Headforwards Solutions Ltd.
Registered Address: FibreHub, Trevenson Lane, Pool, Redruth, Cornwall, TR15 3GF, UK
Registered in England and Wales: 07576641 | VAT Registration Number: GB111315770