Specification by example refers to the use of relatively concrete examples to illustrate how a system should work, as opposed to more formally written specifications expressed in very general terms. Specification by Example is also often interchangeably referred to as Behavior Driven Development or Acceptance Driven Development and Acceptance Test-Driven Development.
There are some very compelling reasons for moving to Specification by Example which we will discuss first and then we will wrap up by discussing the critical cultural change that it can enable. One major benefit of Specification by Example is the transparency it can bring to the testing component of DevOps. By incorporating Specification by Example, we allow the product owner to be able to know precisely which features are being delivered in a particular release, and also know what works and what doesn’t via viewing a simple English like test. Business analyst are able to see exactly how stories have been implemented. The operations team will want to know exactly which features are coming down the pipeline to be delivered into production.
Another benefit is that Specification by Example is that it serves as a vehicle to foster communication between all stakeholders by serving as a common language. The use of Specification by Example forces the use of common verbiage in the organization in order to allow frequent conversations between domain experts and the delivery team so that organizations can lay a foundation for the entire development process.
Specification by Example allows the examples you write to become living documentation, this is accomplished through the automation of the examples, which keep specifications in check when run consistently in the DevOps pipeline. The frequent validation via the tests in the pipeline allows organizations to know that the examples, and conversations are up to date, and when you trust your tests, you can use them as documentation for the entire system. A side benefit is that you can track every example back to the tests that make up that example, which allows teams to know exactly which tests need to be updated whenever an example is changed, replaced or deleted. By validating frequently, we guarantee that the documentation must change every time the product changes.
Possibly the most important component of Specification by Example and probably the least discussed is its ability to become an agent for cultural change inside an organization moving to either Agile or DevOps. By using Specification by Example, we can break the traditional stronghold the Quality Assurance silo has had on testing. When we start using examples inside our Agile teams and get the developers and business side actively involved, what we discover is that this can break down the resistance developers often have to taking over automated testing because with the examples in place the developers often no longer will push back with the concern that they will have to spend time attempting to figure out what needs to be tested, the exact tests and expected outcomes are now laid out for them. In addition, we also break the traditional way in which test cases have been written by Quality Assurance, we focus on the critical behaviors that are called out by the business side through the example creation process and we no longer attempt the blanket approach to testing.