Dev Team: Delivering business value with Behavior Driven Development
Recently many of our Test Driven Development (TDD) practicing developers started realizing that, while unit tests are useful, the way developers write and use them often results in tests and code disconnected from business value. That is, developer unit tests typically express desired code behavior, not desired business value.
And while ostensibly acceptance tests verify business value, LEAN/Agile principles suggest that we might eliminate waste and write the code to meet the business value in the first place! Why write code (and unit tests) that may not meet business value, only to have another layer of testing code tell us so? We miss an opportunity if we wait for developers and testers to both write sufficient code to provide this necessary feedback.
Additionally, one of our LEAN/Agile goals is to blur team member responsibilities so everyone contributes as needed, increasing the team’s effectiveness as a unit. Their goal is delivering business value — not finding bugs, not achieving 100 percent code coverage, not writing one unit test fixture per class.
Getty Images is adopting a comprehensive acceptance test strategy, based on Behavior Driven Development (BDD) concepts, designed to help teams deliver business value via working software. Our approach uses these tools: scenarios, targets and scenario-to-target bindings.
Scenarios capture business value. A scenario describes a desired behavior using a simple textual (i.e. non-code) format, expressed in terms of the business domain and its entities, regardless of possible implementations. These attributes make scenarios ideal for facilitating conversation between the team and their product owner. When a team commits to a story, they and their product owner agree on the set of scenarios that define the acceptance criteria.
Many BDD tools support a simple scenario specification vocabulary called Gherkin. The Gherkin vocabulary provides a few simple keywords to indicate pre- and post-conditions of a scenario, while also allowing for the development of a custom business domain vocabulary.
Consider the following example scenario:
Scenario: Premium Access customers can download Premium Access images
Given a Getty Images customer
Given the customer has a Premium Access agreement
Given the agreement is active
Given the agreement authorizes download of an image
When the customer downloads the image
Then the customer receives the image
The blue terms—Scenario, Given, When, and Then—compose the Gherkin vocabulary. Scenario indicates the business value, Given indicates a pre-condition, When indicates the tested action, and Then indicates a post-condition. The other terms used—Premium Access, agreement, active, image, and downloads—represent entities or actions in the Getty Images business domain.
We know software works when we demonstrate it behaving according to described business value. Because our description, the scenario, is purely textual, we need to define it in a way that also demonstrates the behavior. And because business behaviors occur throughout our various enterprise systems, we want the scenario to target any aspects of the systems involving the behavior.
Defining targets allows us to “test at the right level”, as close to the behavior as possible. A target can be as small as a code class, or as large as an enterprise system. It is simply a logical entity defined for our convenience (see Figure 1). Our developers analyze the collaborators in the behavior, and define a target for their scenario that is at a low enough level to effectively test the behavior. If a single class provides all the behavior, we define the target as that class; if a collaboration of two systems provides the behavior, we define the target to encapsulate both systems. The same scenario can then be bound to any targets as the team sees fit.
Figure 1: The dotted lines illustrate two possible targets defined for Systems A and B. One target is a single class within System A; the other is a collaboration of classes in System A as well as the entire System B.
An intermediate layer of code binds a scenario to a target (see Figure 2). This scenario-to-target binding code essentially defines the meaning of a scenario in terms of a target. It typically resembles the code in our former unit and acceptance tests. It manipulates a target to set up initial state, perform the desired behavior, and confirm the outcome, as specified in a scenario. It ties explicitly to a scenario via a mechanism provided by the BDD tool, which allows for traceability from the behavioral specification (scenario) to the implementing system(s) (target).
Figure 2: A scenario is evaluated against a target through a binding. A scenario can use multiple bindings to verify the same behavior across multiple targets.
Acceptance and Delivery
We accept a scenario when its binding code successfully confirms the outcome. Once we accept all scenarios for a story we consider the story done and deliverable.
We rely on our continuous integration system to deliver working software. It runs all scenarios against their targets after any code check-in, and only propagates through the delivery pipeline the targets whose scenarios pass. Any scenario failures along the way stop delivery and get reported back to the responsible team(s).
We encountered many interesting challenges while adopting this approach. We worked through the challenges by allowing a couple teams to adopt the process as a proof of concept (POC) using the tools and processes of their choosing. The POC teams met regularly to discuss issues and propose solutions. Future articles will explore these challenges.
We incorporated ideas from many places to design our approach. Several of our developers were inspired to seriously pursue adopting BDD after taking a Net Objectives training course on Acceptance Test-Driven Development (http://www.netobjectives.com/courses/story-writing-acceptance-tests). Dan North influenced our understanding of scenarios in the following articles: http://dannorth.net/whats-in-a-story/ and http://dannorth.net/2011/01/31/whose-domain-is-it-anyway/. And finally, the BDD tool SpecFlow (http://specflow.org) inspired us to explore the usefulness of binding a scenario to multiple targets.