Specification By Example

The fact that the same practices have so many names reflects the huge amount of innovation
in this field at the moment. The purpose of this course is to provide an overview of Specification By Example and equip you with the skills to enable this in your own environment.

The purpose of Specification by Example is to create a shared understanding of the story, what it should and should not do. The technique uses examples of the specification (story) to facilitate that understanding. The power of this technique is that the human mind works best with examples.

The Software Delivery Challenge

Ensuring that the software product (code) delivers the functionality that meets the desired business requirements. This is the concept of Building the Right Product

Finding the time and capability to Shift Left.

Shift Left is all about building quality in, instead of trying to fix it at the end of the delivery cycle (UAT or SIT). Fixing at the end requires rework which is an anti-pattern of productivity. Shift Left has been around since we started with testing in 1994, however how often are testers involved before development starts?

Automation for efficiency and effectiveness

Finding the time and capability to automate. Specification by Example (SbE) is a game changer when it comes to automation. If we write the SbE in the format of Given, When, Then, the resulting specification can generate an Executable Specification which a script (Ruby, Java or Python) that becomes an automation asset. This automation asset can be used by a Developer to check their code that it meets the specification. Once code is delivered it can be used by business to confirm that the code is delivering the desired business requirement. If this all happens before a single line of code is written then we have truly enabled building quality in.

The most important nuance to grasp is that it is a specification and NOT a test. What this means is that there is still testing to be carried out once the code is written. That is not to say that you cannot build tests up front.

When starting off with Specification by Example, make sure that you focus on creating the shared understanding of a feature must work and deliver to the required business requirement.

 What we do (the basic practice)

• Use Specification-by-Example to facilitate communication on business needs as defined in the design phase
• Use the Power of 3 perspectives:
  • Business Analysis
  • Development
  • Quality & Testing
• Ensure peer review of the Specification-by-Example 
• Produce [create] DevTest Assets before coding starts. These assets are easily automated and used in different phases. This is done by writing the Specification by Example (SbE) in the format of Given When Then
• Design, create and supply Test Data to support execution of Specification-by-Example (Given When Then)

Some of the names that teams use for these practices are:

> Agile acceptance testing
> Acceptance Test-Driven Development
> Example-Driven Development
> Story testing
> Behaviour-Driven Development
> Specification by Example

Our preference is for Behaviour-Driven-Development as we are describing the behaviour of the system. As such it keeps the focus on specifications and not tests.

This course is a redaction of the book Specification by Example: How successful teams deliver the right software by Gojko Adzic.  The course creator is thankful to the author for granting permission to use the material and concepts from the book for the creation of this course.