Behavior Driven Development uses conversations around concrete examples of system behavior to get a common understanding of features that are going to be implemented. This is the heart of BDD, as the quality of those examples affects the whole development process. How to organize this conversation in practice? There are three approaches, that I would like to present.
The whole team workshop
This approach is good for teams new to BDD. At an early stage of iteration gather everyone involved (Bussines Analysts, Developers, Testers) to start a conversation about scenarios that examine a feature to be implemented. As everyone involved gives input and instant feedback, high-quality examples are created as a result of this meeting. Additionally, it gives the team a shared understanding of the features. But it comes at a high cost: such a meeting is hard to organize (people are busy) and expensive (people hours).
This is an alternative to the whole team workshop – a less expensive approach, but still, able to produce fairly high-quality scenarios. From the whole team, choose three members (three Amigos) – a developer, a tester and a business analyst. They can sit around a computer to write the initial draft of scenarios. Each of them brings something else to the table. A tester focuses on details and border cases. A developer gives a technical understanding, whereas a business analyst can provide the business background. The quality of the created scenarios depends on representatives being chosen – their experience and familiarity with the domain related to the features.
Business Analyst leading
In this approach, a Business Analyst creates scenarios for review by a developer and tester. During a review, they may suggest a rephrasing of steps for automation tools purpose. It does not build a shared understanding of a feature as good as the previous approaches, but it can be a good alternative when the Business Analyst is part of different department or location.
Squish IDE offers a powerful editor for creating Feature files, which can be used in all approaches described above.
While typing a Step in a Scenario, the IDE suggests already defined Steps that match what you are typing. Reusing existing Steps in Scenarios makes automation of such scenarios easier.