BDD from 50,000 feet
Dec 14, 2021
So what does BDD bring to the table? Here’s a (slightly oversimplified) perspective. Let’s say Chris’s company needs a new module for its accounting software.
When Chris wants to add a new feature, the process goes something like this (see figure 1.1):
1. Chris tells a business analyst how he would like the feature to work.
2. The business analyst translates Chris’s requests into a set of requirements for
the developers, describing what the software should do. These requirements
are written in English and stored in a Microsoft Word document.
3. The developer translates the requirements into code and unit tests—written in
Java, C#, or some other programming language—in order to implement the new feature.
4. The tester translates the requirements in the Word document into test cases,
and uses them to verify that the new feature meets the requirements.
5. Documentation engineers then translate the working software and code back
into plain English technical and functional documentation.
There are many opportunities for information to get lost in translation, be misunderstood,
or just be ignored. Chances are that the new module itself may not do exactly
what was required and that the documentation won’t reflect the initial requirements
that Chris gave the analyst.
Figure 1.1 The traditional development process provides many opportunities for misunderstandings and miscommunication.
Building software that makes a difference
Chris’s friend Sarah runs another company that just introduced BDD. In a team practicing
BDD, the business analysts, developers, and testers collaborate to understand
and define the requirements together (see figure 1.2). They use a common language
that allows for an easy, less ambiguous path from end-user requirements to usable,
automatable tests. These tests specify how the software should behave, and they guide
the developers in building working software that focuses on features that really matter
to the business.
1. Like Chris, Sarah talks to a business analyst about what she wants. To reduce the
risk of misunderstandings and hidden assumptions, they talk through concrete
examples of what the feature should do.
2. Before work starts on the feature, the business analyst gets together with the
developer and tester who will be working on it, and they have a conversation
about the feature. In this conversation, they discuss and translate key examples
of how the feature should work into a set of requirements written in a structured,
English-language format often referred to as Gherkin.
3. The developer uses a BDD tool to turn these requirements into a set of automated
tests that run against the application code and help objectively determine
when a feature is finished.
4.The tester uses the results of these tests as the starting point for manual and
exploratory tests.
5.The automated tests act as low-level technical documentation, and provide
up-to-date examples of how the system works. Sarah can review the test reports to
see what features have been delivered, and whether they work the way she expected.
Compared to Chris’s scenario, Sarah’s team makes heavy use of conversations and examples to reduce the amount of information lost in translation. Every stage beyond
step 2 starts with the specifications written in Gherkin, which are based on concrete examples provided by Sarah. In this way, a great deal of the ambiguity in translating
the client’s initial requirements into code, reports, and documentation is removed. We’ll discuss all of these points in detail throughout the rest of the book. You’ll
learn ways to help ensure that your code is of high quality, solid, well tested, and well documented. You’ll learn how to write more effective unit tests and more meaningful
automated acceptance criteria. You’ll also learn how to ensure that the features you deliver solve the right problems and provide real benefit to the users and the business.
