September 20, 2016 | Written by: Laurent PY
Categorized: Community | DevOps
Share this post:
In the context of digital transformation and dramatic acceleration of software deployments, working in silos (Business, Developers, Testers, IT…) is no longer an option. Agile, and now DevOps culture, are getting a lot of traction as they break silos with cross functional teams. Therefore, rapid iterations and quick feedbacks are king.
For organizations deploying new software in production several times a day, one of the most challenging transformation issues is the need to revolutionize testing. In an era of continuous deployment and updates, there’s no time to have QA teams identify a problem and kick it back to the developers. The times are gone when you could test your app after the development and before going in production.
This is where Behavior Driven Development (BDD) comes in. BDD is a powerful approach that enables your team to align on the definition of what should be built, and when.
First, the developers, testers and business analysts explore the problem domain, and collaborate to produce concrete examples that describe the behavior they want.
Every test should tell a story about your application
These examples define the boundaries of the user stories and are designed prior to the development. It’s a great way to minimize waste and avoid development of features that are not needed, or that do not meet business expectations.
These concepts are quite simple and were initially formalized by Dan North.
Using BDD with Gherkin syntax
Gherkin is plain-text language with extra structure included to make it easy to learn by non-programmers. It allows concise description of examples to illustrate business rules in most real-world domains. One of the biggest advantages is that it clearly highlights the intent of the example/test development application.
You can follow these basic steps to begin using BDD and Gherkin syntax:
- Start with your user stories.
- As a team, go through your user stories and write BDD scenarios using the keywords GIVEN, WHEN, and THEN (AND, BUT can be used as well)
- GIVEN is your setup. For example: “GIVEN the credit card is valid”
- WHEN is your action. For example: “WHEN I request $50”
- THEN is your assertion: For example: “THEN the ATM should dispense $50”
- Capture the BDD scenarios in a location that is public for everyone to see. Hiptest is a good choice 🙂
- Automate your BDD scenarios.
- First, the execution will fail as the feature is not yet implemented
- Automation clearly requires development skill. You’ll want to learn how to build a test automation framework that scales.
- Implement the features
- Run the automated BDD scenarios to show the feature is completed
Here is a sample Gherkin document:
[code]<span class="k">Feature:</span><span class="nf"> Account Holder withdraws cash[/code]
Scenario: Account has sufficient funds
Given the account balance is $100
And the card is valid
And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20
And the account balance should be $80
Then the card should be returned
The next post will focus on a step-by-step implementation of BDD with Bluemix and Hiptest.
Check out Hiptest in the Bluemix catalog
If you have any questions, or would like to chat further about BDD please reach out to firstname.lastname@example.org.