BDD in Action
There are many opportunities for information to get lost in translation, be misunder-
stood, 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 user gave the analyst.
BDD
The B in BDD stands for Behaviour, the desired behaviour of the software to be developed. The DD part stands for Driven-Development. BDD is an approach for building a shared understanding on what software to build by working through examples.
- BDD helps teams focus their efforts on identifying, understanding, and building valuable features that matter to businesses, and it makes sure that these features are well designed and well implemented.
- BDD practitioners use conversations around concrete examples of system behavior to help understand how features will provide value to the business.
- BDD encourages business analysts, software developers, and testers to collaborate more closely by enabling them to express requirements in a more testable way, in a form that both the development team and business stakeholders can easily understand.
Team makes heavy use of conversations and examples
to reduce the amount of information lost in translation.
BDD principles and practices
identifying business goals and looking for features that will help deliver these goals.
they use concrete examples to illus-
trate these features.
these examples are automated in the form of executable specifications, which both validate the software and provide automatically updated technical and functional documentation.
FOCUS ON FEATURES THAT DELIVER BUSINESS VALUE
Rather than accepting a list of feature requests from the users with no questions asked, teams try to understand the core business goals underlying the project, proposing only features that can be demonstrated to support these business goals.
Business Goal
“to attract more clients by providing a simple and convenient way for clients to manage their accounts.”
Feature
“Transfer funds to an overseas account.”
“Transfer funds between a client’s accounts.”
WORK TOGETHER TO SPECIFY FEATURES
BDD is a highly collaborative practice, both between users and the development team, and within the team itself. Business analysts, developers, and testers work together with the end users to define and specify features, and team members draw ideas from their individual experience and know-how. This approach is highly efficient.
EMBRACE UNCERTAINTY
Rather than attempting to lock down the specifications at the start of the project, BDD practitioners assume that their understand-
ing of the requirements, will evolve and change throughout the life of a project. They try to get early feedback from the users and stakeholders to ensure that they’re on track.
ILLUSTRATE FEATURES WITH CONCRETE EXAMPLES
DON ’ T WRITE AUTOMATED TESTS , WRITE EXECUTABLE SPECIFICATIONS
- Acceptance criteria give the team a way to objectively judge whether a feature has been implemented correctly.
- Teams turn these acceptance criteria into automated acceptance tests or, more precisely, into executable specifications.
- An executable specification is an automated test that illustrates and verifies how the application delivers a specific business requirement.
DON ’ T WRITE UNIT TESTS , WRITE LOW - LEVEL SPECIFICATIONS
- The developer won’t think in terms of writing unit tests for a par-ticular class, but of writing technical specifications describing how the application should behave, such as how it should respond to certain inputs or what it should do in a given situation.
- These low-level specifications flow naturally from the high-level acceptance criteria, and help developers design and document the application code in the context of delivering high-level features
DELIVER LIVING DOCUMENTATION
- This documentation is always up to date and requires little or no manual maintenance.
- It’s automatically produced from the latest version of the application.
- Each application feature is described in readable terms and is illustrated by a few key examples.
USE LIVING DOCUMENTATION
SUPPORT ONGOING MAINTENANCE WORK
- The high-level executable specifications help new developers understand the business goals and flow of the application.
- Executable specifications at the unit-testing level provide detailed worked examples of how particular features have been implemented.
When a developer makes a change, it may cause existing executable specifications to break, and when this happens, there are usually two possible causes:
- The broken executable specification may no longer reflect the new business requirements. In this case, the executable specification can be updated or deleted.
- The code change has broken an existing requirement. This is a bug in the new code that needs to be fixed.
Benefits and protential challenges of BDD
Benefits of BDD
- Reduced waste
- Reduced costs
- Easier and safer changes
- Faster Release
Potential Challenges
- BDD requires high business engagement and collaboration.
- BDD works best in Agile or iterative context.
- BDD doesn't work well in a silo.
- Poorly written tests can lead to higher test-maintenance costs.
Give me concrete Example!
More
-
[JCConf 2015] Bridging the gap between Business and IT using Cucumber
-
[Modern Web 2015] The Speed & The Enthusiasm