BDD is not a test automation tool. Automation is a by-product. BDD is about capturing the intended behaviour of the system. The feature files produced should form the basis of a number of testing activities.

• They should be developed by the team, not just the testers
• They form the basis of automated scripts for demonstrating that functionality is complete
• They should form the basis of manual UAT testing and be what is formally accepted
• They should be used to describe the behaviour of inter-operating systems (SIT)
• They can be used to describe non-functional requirements

We had a Q&A with Tim Myerscough: a Principal Consultant at MagenTys and he answered some common questions on BDD to shed some light on exactly what BDD is and what it does.

How would you define BDD in layman’s terms for someone who doesn’t have a technical background?

BDD is an approach to help ensure that developers build the right thing. It describes the behaviour expected of the system using specific examples to avoid confusion.

How would you define BDD to someone with a technical background?

BDD is a development approach using a specific mindset. It is the logical extension of Test Driven Development (TDD), focussing on the business intent and expected behaviour of the system.

Requirements are specified in a domain specific language (DSL), readable by both technical and non-technical people. BDD focusses on collaboration and discussion, using concrete examples, to elicit the requirements and build a shared understanding.

BDD Is TDD from the business point of view. BDD identifies the set of acceptance tests up front, to provide a definition of done for a feature. The acceptance tests are automatable, providing living documentation for what the system actually does.

Want more like this?

Want more like this?

Insight delivered to your inbox

Keep up to date with our free email. Hand picked whitepapers and posts from our blog, as well as exclusive videos and webinar invitations keep our Users one step ahead.

sign up

By clicking 'SIGN UP', you agree to our Terms of Use and Privacy Policy

SIGN UP

By clicking 'SIGN UP', you agree to our Terms of Use and Privacy Policy

What are the common mistakes people make when using BDD?

The single biggest mistake I see is the use of imperative language that constrains the application. Attempting to capture behaviour at a fine grained level of detail results in tests that are difficult to read and tied to the implementation of the user interface.

Compare:

• Scenario: Login (Imperative)
• Given I have navigated to the login page
• When I enter “billy_bob” into the username field
• And I enter “password1″ into the password field
• And I click on the “Login” button
• Then I shall be taken to the home page
• And I shall see “Hello Billy Bob!”

With:

• Scenario: Login (declarative)
• Given I have navigated to the login page
• When I login with valid credentials
• Then I shall be taken to the home page
• And I shall see a welcome message

What are the key benefits that BDD has offered to you as a tester?

I don’t just think of the benefits as a tester, but to the whole team.

As a tester, I am involved in discussions up front. In traditional development, testers often don’t get involved until the application has already been developed and the requirements have been written. In BDD the testers are involved from the outset. Automation removes the repetitive aspects of regression testing, instead enabling greater exploratory and usability testing.

As a developer, BDD provides the definition of done for a piece of work. It explicitly captures what a developer has to do prior to stating that they think something is complete – they have to go through the requirements to check that they are met. It also helps with planning/estimation. Having a set of scenarios and expectations clearly expresses the intent and helps focus estimation discussions around what will be required. It also makes it really easy for scoping. If a feature looks like it will be too much to deliver for a sprint, just split out scenarios that will be delivered later.

As a BA, everyone has a clear understanding of what the system is supposed to do. I also get the confidence that the team are building the right thing, not just building the thing right.

What are the benefits BDD offers an organisation?

As an organisation, software delivered is of higher quality, with a low risk of regressions. This allows faster release cycles and quicker delivery of business value.

The risk of misinterpretation of requirements is mitigated by allowing regular review and ratification of the requirements demonstrated by working software. As opposed to traditional delivery, where acceptance testing is often delayed to the end of the project when it is too late to fix any problems.