Software development is all about translating business requirements into working software. Business analysts come up with a set of requirements that is communicated to development teams via user stories and acceptance tests describing how the user interface should function. The problem is that it’s difficult to automate user stories and acceptance tests. That is, there’s no good way for developers to run a command that tells them if the underlying code meets the requirements. And, this automation is a critical component of Agile development—it helps developers move quickly without the fear of breaking things. Let’s take a look at how behavior-driven development, or BDD, addresses these concerns through executable specifications. Executable specifications make it easy to get business and technical teams on the same page via a common language.

How Executable Specifications Work

Behavior-driven development makes it easy to get business and technical teams on the same page by introducing a common domain-specific language, or DSL. Business analysts write requirements using language that’s very similar to written prose and technical teams can automatically turn that language into an executable test. Unlike test-driven development, or TDD, the abstraction is closer to the business domain than specific methods and classes contained within the code. Let’s look at a quick example scenario:

# Comment

@tag

Feature: Users should be able to book appointments.



Scenario: A user wants to book an appointment.

Given a user has booked an appointment

When the booking status is timed out

Then the appointment will be not confirmed

Gherkin is the most commonly used plain-text language for writing executable specifications in Given-When-Then-And-But steps. These scenarios are commonly saved as `.feature` files. When the executable specification is run, the BDD framework generates a blueprint for step definitions that are written using browser automation libraries or frameworks. For example, the above specification could execute a step definition that looks like this:

Then(/^the appointment will be “(.*?)”$/) do |confirmationStatus|

# confirmationStatus = "not confirmed"

page.should have_status(confirmationStatus)

end

Scenarios are converted into code where simple regular expressions extract key variables for use in automation frameworks. In the above example, Capybara is used to create the step definition and the confirmation status is extracted into the `confirmationStatus` variable. You can add multiple data sets to use in a single scenario to cover a wider range of example use cases. For example, the above scenario could include a multiple booking status examples (other than “timed out”) and respond with multiple confirmation statuses (“confirmed” and “not confirmed”). That way, you can test to see how each one responds. There are many benefits to using this approach when writing tests. For example, if a business analyst wants a high-level change, they can easily adjust the Gherkin plain-text example and it will be automatically converted into executable tests that are spelled out in the step definitions. There’s no need to change the technical step definitions. There are many different BDD frameworks that enable you to create these kinds of executable specifications, but the two most popular are Cucumber and Specflow. Similarly, there are many different automation frameworks that integrate with BDD frameworks, but the most popular options are Selenium and Robot Framework.

Where They Fit in Agile & Scrum

Behavior-driven development and executable specifications are designed to reduce wasteful activities in software development, such as vague requirements or slow feedback cycles. The approach eliminates the communication gap between business analysts and developers while ensuring that new changes don’t unexpectedly break functionality. [content_upgrade cu_id="4837"]Download our Free Guide to Writing a Good Executable Specification! [content_upgrade_button]Click Here[/content_upgrade_button][/content_upgrade] After writing a user story and acceptance criteria, product, developing, and testing team members should come up with examples to illustrate each acceptance criteria. These examples can be translated into executable specifications that ensure the rules are followed. Some development teams write executable specifications during the same meeting, especially when the team is new to business-driven development. In established teams, writing executable specifications can be assigned to a developer and/or tester without the product person. These meetings are helpful to have on a bi-daily basis using one story and about 25 minutes of attention. By focusing on these short bursts, your team can continue to make meaningful progress in development and avoid the burnout that inevitably comes when trying to do too much at once.

Simplifying the Process

HipTest provides an easy interface for building, executing, and verifying executable specifications. Product managers can easily login, define scenarios, and verify test results. In addition, they can easily define action words, or reusable steps, and organize scenarios based on various metrics. This helps keep everything organized from a high-level standpoint. [caption id="attachment_4714" align="alignnone" width="677"] Example of a Scenario in HipTest - Source: HipTest[/caption] For developers, HipTest publisher lets you extract scenarios from HipTest and generate feature files—or executable specifications—for different frameworks. You can also import existing feature files into HipTest to easily bring the testing suite up-to-date upon initial setup. You can even integrate action words with an automation framework to make writing step definitions a lot easier. When doing so, you can choose between loose coupling that requires input from the automation team or tight coupling that keeps almost everything in HipTest. HipTest also integrates with Continuous Integration servers for testing automation. After installing HipTest publisher, you can publish the results of a CI build into HipTest to keep everything up-to-date. You can even integrate external tests into HipTest to keep everything under one roof. Everyone can measure progress using tags that are setup in scenarios. For instance, you can tag something by priority—low, medium, or high—or by status—todo, wip, and in-production. The result is an easy-to-understand read on where various user stories stand in development.

The Bottom Line

Executable specifications enable business and technical teams to get on the same page by using a common language. Business analysts can write specifications in written prose and developers can easily convert the specifications into automated tests that can be run against their code. HipTest helps manage these executable specifications by providing an interface for business analysts and automated tooling for developers to show progress in real-time. Sign up for a free trial or request a demo to see how HipTest can dramatically improve your development workflow.