Elisabeth Hendricksson stated at Turku Agile Day 2010 that “Specs is an abbreviation for speculations”. She is right, specs are often speculations. How can this be avoided? Execution of code doesn’t leave any room for speculation. If the specs can be executed, they aren’t speculations anymore.

Acceptance tests and requirements are linked. You can’t have one without the other. The tests clarify and amplify the requirements. A test that fails shows that the system does not properly implement a requirement. A test that passes is a specification of how the system works.

Learn how software applications can be specified, continuously developed, tested and delivered and how testing supports the flow from requirements through to acceptable systems. In the Agile community, Acceptance-Test Driven Development (ATDD), Behaviour-Driven Development (BDD), Test-Driven Development (TDD) and Specification by Example are gaining greater acceptance as an effective approach to developing systems of high quality and business value.

The ideas behind Behavior-Driven Development (BDD), Specification by Example and Agile acceptance testing are deceivingly simple, but have proved far from easy to implement. Yet most of the complaints online come from misunderstood ideas which lead to misguided attempts. This talk busts the myths around these techniques and shows how successful teams all over the world use them to successfully deliver the right stuff using these techniques.

Feature injection is a business analysis approach that focuses on business value, an approach similar to Behavior Driven Development (BDD). It transfers knowledge to the team about how the project can deliver value and what are the features needed to deliver that value. Examples are used to transfer this information to the team in the form with the goal to eliminate the waste of separate requirements specifications and tests. Why is it call Feature Injection? Because “The process of pulling value from a project injects features into the system”.

These two videos show the Behaviour Driven Development (BDD) cycle using Ruby, Cucumber and RSpec.

TickSpec is a lightweight F# Behavior Driven Development (BDD) framework to manage and test your requirements. You describe behavior in plain text using the Gherkin business language (given, when, then) and then you execute the requirements in C# or F#.

This article presents the best practices of using RSpec, a Behavior-Driven Development (BDD) tool for Ruby programmers.

In this blog post, Mehdi Khalili explains that Behavior Driven Development can help you in more than one way. First and foremost it removes the ambiguity from the requirements, but taking it a step further could give you a lot of significant benefits.

Many of the most common problems people have with implementing BDD or agile acceptance testing come from a misalignment of conceptual models. By changing our view at the specifications/tests we can make most of those issues go away instantly. This post explains the principle of symmetric change: one small change in a business model should require one small change to executable specifications.