Skip to main content
All CollectionsGetting Started
The Basics of BDD in Behave Pro
The Basics of BDD in Behave Pro

A brief a guide to get you up to speed with the important BDD concepts within Jira when using Behave Pro

Alan Parkinson avatar
Written by Alan Parkinson
Updated over 3 years ago

Ever stood in a Sprint demonstration and the product owner said: “That’s not what I wanted”? This is a common problem in software projects, in fact, one of the biggest sources of bugs and unnecessary rework. Most people wrongly associate BDD with Test Automation, but if applied correctly it can also solve the “That’s not what I wanted” problem by building a shared understanding of the User Story between the product owner, developers, and testers.

When adopting the BDD process it's best to think about the process in three stages:

  • Discovery - Where the team collaboratively discuss requirements for the feature they intend to deliver to develop a shared understanding of what the business wants.

  • Capture - As the team gains a shared understanding of what they need to deliver, they can capture key examples that describe what the team intends to deliver.

  • Automation - The captured key examples can then be automated by developers to help them guide their development 

Note: If you are just writing Given When Then just for Test automation purposes you are not really doing BDD. You might benefit switching away from a BDD automation tool to a Test Automation tool 

Let's take a look at an example of these three stages in more detail and learn how Behave Pro can help support the process

Discovery

The process starts with a user story being taken from your JIRA backlog, that might look something like this:

At this current time the user story is vague and needs more detail. The team could start work on this story, but their is a strong risk of the requirements being misinterpreted resulting in a delivery that doesn't match what the business wants. This leads to additional re-work and wasted time and effort.

To avoid this risk a team that practises a BDD will take the time to discuss the story before going into development. The discussion will take place informally and consist of a Developer, Tester and Product Owner (or similar) which is sometimes known as a 'Three amigos' session:

During this collaborative session the Product Owner will introduce the user story and share how they want the feature to behave. For example:

"Our users are frustrated that they only find out about train delays once they get to the station. I want our application to send a notification to users mobiles with details on the delay as soon as the train is marked as delayed"

Once the user story has been introduced the Developers and Testers can then ask questions to discover more about the requirements and discuss solutions, for example:

  • When you say details, what exact details do you want sent?

  • What sort of notification? We could send an in-app notification or text message

  • How does the user register for notifications for a specific train?

For teams that are new they can try different discovery techniques to see which reveals new information for them.

They may also jot down informal notes such as descriptions of notifications, drawings of the UI, titles of examples 'User is informed of delay'. These can be used for capturing examples later.

The conversation helps the whole team to develop a shared understanding of what is 

Capture

Either during or after the session the team captures key examples from the discussion that illustrate the key behaviours to be delivered. This is written using Gherkin syntax which commonly is made up of Given, When and Then to create examples like this:

The captured examples help teams to agree behaviour and to confirm has a shared understanding of the requirements. By either raising a question or marking the captured examples as ready:

Automation

Once the key examples have been captured and the team have agreed they are ready, the developer can then begin to use them as automated acceptance tests to guide the development using a process known as Outside in Development.

In Behave Pro developers have the option to either save feature files directly to Git repositories (GitHub or Bitbucket) or extract the feature files using our builds tools to create automated acceptance tests with a tool of their choice such as Cucumber or SpecFlow. The developer will then follow the outside in development process:

  1. Create an automated acceptance test that is attempting to check for a feature that does not exist and fails

  2. Write enough production code to make the automated acceptance test pass

  3. Refactor the production code to be cleaner, whilst ensuring the automated acceptance test still passes

Once the all the acceptance tests are passing this gives the developer confidence that they have completed the work and that it is what the business has asked for. Thus reducing re-work and leaving more time for new development work.

What next?

Because building the shared understanding about the User story is so important you might want to look into Behave Pro's "Questions and Ready" feature that allows team members to 'vote' their understanding of stories/issues.

You can also integrate one of Behave Pro's build tools into your projects build process to export all the feature files for your project to a local directory before executing Cucumber or your preferred automation tool of choice.  Available build tools are Maven, Gradle, MSBuild (C#/.net), Rake, NodeJS, Python and command line clients in Ruby and Python. Check out each tools documentation to understand how to configure them.

Did this answer your question?