BDD Specifications by Example - Behavior Driven Development

What is BDD - Specifications by Example?

Gojko Adzic is known as the author of ‘Specification by Example’, “Specification by Example is a set of process patterns that facilitate change in software products to ensure that the right product is delivered efficiently.”
Specification by Example is a synergistic process to deal with prerequisites and business-oriented functional tests for programming products in view of examples of describing with reasonable cases rather than theoretical explanations.

Specification by Example – Overview

The main objective of Specification by Example is to concentrate on advancement and conveyance of organized, obvious, business necessities. While the idea of Specification by Example in itself is moderately new, it is basically a rethinking of existing practices.
It supports a very specific, concise vocabulary known as ubiquitous language that −
  • Enables executable requirements.
  • Is used by everyone in the team.
  • Is created by a cross-functional team.
  • Captures everyone's understanding.
Specification by Example can be utilized as an immediate contribution to building Automated tests that presents the business scenario. Accordingly, the objective of Specification by Example is on building the correct item and building the product right.

Purpose of Specification by Example

The main aim of the Specification by Example is to design the right final product. It mainly focuses on shared understanding by creating a single source of truth. It provides automation of acceptance criteria so that main criteria will be on defect prevention rather than defect detection. It also uses to promote test early to explore the defects early.

Use of SbE

Specification by Example is used to show the expected system behavior which explains about business value. The example is described with concrete and real life examples. These examples are mainly used to focus on executable requirements that are −
  • Testable without translation.
  • Captured in live documentation.
Here are the reasons why we use examples to explain unique specifications:
  • They are easier to understand.
  • They are harder to misinterpret.

Advantages of SbE

The main advantages of using Specification by Example are −
  • Increased quality
  • Reduced waste
  • Reduced risk of production defects
  • Focused effort
  • Changes can be made more safely
  • Improved business involvement

Applications of SbE

Specification by Example to find applications in −
  • Either complex business or complex organization.
  • Does not work well for purely technical problems.
  • Does not work well for UI focused software products.
  • Can be applied to legacy systems as well.

SbE and Acceptance Testing

The main advantages of Specification by Example while using Acceptance testing are −
  • One single example is used for both, detailed requirements and testing
  • Progress of the project is available in terms of Acceptance tests −
    • Each test is to test a behavior.
    • A test is either passing for a behavior or it is not.
    • A passing test represents that the particular behavior is completed.
    • If a project that requires 100 behaviors to be completed has 60 behaviors completed, then it is 60% finished.
  • Testers follow to go defect fixing to defect prevention, and they contribute to the design of the solution.
  • Automation provides instant understanding of the usage of a requirement change on the solution.

Specification by Example – What it means for different Roles

The main objective of Specification by Example is increase ion in the team, which includes the customers throughout the project to deliver business value. Everyone for better understandability uses same Vocabulary.

RoleUse of SbE

Role Use of SbE
Business Analyst
  • Requirements are unambiguous and without functional gaps.

  • Developers, actually read the specifications.

  • Developers understand better, what is being developed.

  • Development progress is tracked better by counting the specifications that have been developed correctly.

  • Testers understand better, what is being tested.

  • Testers are involved from the beginning and have a role in the design.

  • Testers work toward defect prevention rather than defect detection.

  • Time is saved by identifying errors from the beginning.

  • A quality product is produced from the beginning.

SbE – A Set of Process Patterns

As we mentioned in the beginning of this chapter, Specification by Example is mentioned as a set of process patterns which provides to detect the change in software products to make sure of the right product is delivered or not.
The process patterns are −
  • Collaborative specification
  • Illustrating specifications using examples
  • Refining the specification
  • Automating examples
  • Validating frequently
  • Living documentation

Collaborative Specification

The main objectives of collaborative specification are to −
  • Get the various roles in a team to have a common understanding and a shared vocabulary.
  • Get everyone involved in the project so that they can contribute their different perspectives about a feature.
  • Ensure shared communication and ownership of the features.
These objectives are met in a detail workshop otherwise called the Three amigos meeting. The Three Amigos are BA, QA and the designer. Despite the fact that there are different parts in the task, these three would be capable and responsible from definition to the conveyance of the highlights.

During the meeting −

  • The Business Analyst (BA) presents the requirements and tests for a new feature.
  • The three Amigos (BA, Developer, and QA) discuss the new feature and review the specifications.
  • The QA and developer also identify the missing requirements.
  • The three Amigos
    • Utilize a shared model using a ubiquitous language.
    • Use domain vocabulary (A glossary is maintained if required).
    • Look for differences and conflicts.
  • Do not jump to implementation details at this point.
  • Reach a consensus about whether a feature was specified sufficiently.
  • A shared sense of requirements and test ownership facilitates quality specifications
  • The requirements are presented as scenarios, which provide explicit, unambiguous requirements. A scenario is an example of the system’s behavior from the users’ perspective.

Illustrating Specification using Examples

Scenarios are explained by using the Given-When-Then structure to generate a testable specification −
Given <some precondition>
And <additional preconditions> Optional
When <an action/trigger occurs>
Then <some post condition>
And <additional post conditions> Optional
This above description is an example of a behavior of the system. It also provides details about an Acceptance criterion of the system.
While the team discusses about the examples then outcome will be saved until the agreement examples include the feature's expected behavior. This creates good test coverage.

Refining the Specification

To refine a specification,
  • Be precise in writing the examples. If an example turns to be complex, split it into simpler examples.
  • Focus on business perspective and avoid technical details.
  • Consider both positive and negative conditions.
  • Adhere to the domain specific vocabulary.
  • Discuss the examples with the customer.
    • Choose conversations to accomplish this.
    • Consider only those examples that the customer is interested in. This enables production of the required code only and avoids covering every possible combination, that may not be required
  • To make sure that the scenario clears all the test cases for that scenario must pass. To increase the specifications to make them testable. The test cases which include various ranges and data values (boundary and corner cases) and business rules will create changes in data.
  • Mention about the additional business rules like complex calculations, data manipulation / transformation, etc.
  • Add only non-functional scenarios (e.g. performance, load, usability, etc.) as Specification by Example

Automating Examples

The automation layer should be simple by keeping the wiring of the specification to the system under test. To perform this you can use a tool.
Perform testing and automation uses Domain Specific Language (DSL) and displays a clear connection between inputs and outputs. We need to focus on specification but not on script. Make sure that you need to make the precise tests and should be easy to understand and testable.

Validating Frequently

We need to add an example validation in the process of development with every modification happens in the process. To get the quality product you can use many techniques and tools based on three key principles- Test Early, Test Well and Test Often.
You can execute these tests randomly to find the weak links if any. Usually the examples present the behaviors that help to track the progress and a behavior of the test in the process to complete only after the corresponding test passes.

Living Documentation

Keep the specifications as simple and short as possible. Organize the specifications and evolve them as work progresses. Make the documentation accessible for all in the team.

Specification by Example Process Steps

Following example showcases the process steps in Specification by Example.


Anti-patterns are known as certain patterns in software development which is known as a bad programming practice. In the process of design patterns, these are considered as common approaches to common problems. These are formalized and called as a good development practice, anti-patterns are the opposite and are undesirable.
Anti-patterns give rise to various problems.

Anti-pattern Problems
No collaboration
  • Many assumptions

  • Building wrong thing

  • Testing wrong thing

  • Unaware when code is finished

Unaware when code is finished
  • Hard to maintain tests

  • Hard to understand spec

  • Loss of interest from business representatives

Too detailed or too UI centric examples
  • Hard to maintain tests

  • Hard to understand specifications

  • Loss of interest from business representatives

Underestimating effort required
  • Teams think they have failed and get disappointed early

Solution to the Problems - Quality

You can ensure the quality of a product by observing the anti-patterns. You can follow below practices to overcome the challenges created by anti-patterns −
  • Get together to specify using examples.
  • Clean up and improve the examples.
  • Write a code, which satisfies the examples
  • Automate the examples and deploy.
  • Repeat the approach for every user story.
To solve the problems due to anti-patterns means adherence to −
  • Collaboration.
  • Focusing on what.
  • Focusing on Business.
  • Be prepared.
Let us understand what each of the above mean.


In collaboration −
  • Business people, developers and testers give input from their own perspectives.
  • Automated examples prove that the team has built the correct thing.
  • The process is more valuable than the tests themselves.

Focusing on what

You must focus on the question - ‘what.’ While focusing on ‘what’ −
  • Do not try to cover all the possible cases.
  • Do not forget to use different kind of tests.
  • Keep examples as simple as possible.
  • Examples should be easily understandable by the users of the system.
  • Tools should not play an important part in the workshops.

Focusing on Business

To focus on the business −
  • Keep specification at business intent.
  • Include business in creating and reviewing specs.
  • Hide all the details in the automation layer.

Be prepared

Be prepared for the following −
  • Benefits are not immediately apparent, even while the team practices are changed.
  • Introducing SbE is challenging.
  • Requires time and investments.
  • Automated testing does not come free.


Using tool sis not must for Specification by Example. For this several tools are available. There are cases that are successful following Specification by Example even without using a tool.
The following tools support Specification by Example −
  • Cucumber
  • SpecFlow
  • Fitnesse
  • Jbehave
  • Concordion
  • Behat
  • Jasmine
  • Relish
  • Speclog

Behavior Driven Development Related Tutorials

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Behavior Driven Development Topics