Implementing BDD Automation & Gherkin
What is BDD?
The classic way to describe tests in BDD workflow is to put then in the form of Given, When, Then. Given describes the current system state or a set of preconditions for a test. BDD automation framework is a behavior test where the behavior or set of test steps that your test will perform. Then is where assertions, or the expected changes from your test, are described. The behavior driven development example of a test is done in something very close to English, which might look like this:
GIVEN I am in a Amazon.com cart with 1 copy of The Shape of Actions WHEN I apply a 10 percent discount code THEN Total = total - (total * 0.10)
This part of the test would probably be written by a product manager or maybe a non-technical tester. Interpreters can't work with English though, code has to be written to make that set of descriptions useful, so the roles gather to create the code above, which is actually in Gherkin, a programmable language. After the meeting the programmer can write the ruby (or Java, or .net) code that the Gherkin will call.
Rather than calling something in this format a test, people that do behaviour driven testing call this a scenario or a specification. Behaviour Driven Development is not a testing technique. Testing is part of a product strategy that can help to discover quality related information that might affect the future of the product. BDD test automation on the other hand, is a development strategy, or maybe a product management strategy if you look at it through the right lens. It acts as a reminder to developers about the value of what they are building and helps them to build the right thing the first time around. (The automated checks that remain after behavioral driven development testing is done can be part of a strong risk management strategy.)
What to Keep In Mind When Getting Started with Behavior Driven Testing
Even though behavior driven development framework and BDD testing tools can create a nice middle ground between technical staff and the business units, there are a few things to be aware of. Behavior Driven Development is often used to create a set of acceptance tests. The big gamble is that the product should be releasable as soon as all of these tests pass. Given/When/Then tests check only the "then" condition, and assume "... and nothing else bad happens." That can be a big assumption to make.
I like to flip the idea on its side, and think of BDD process as rejection criteria. That is to say, while a failing test guarantees the software is not ready to ship, but a passing test does not mean the product is ready to release.
Also, keep in mind that behavioral driven development scenarios tend to be dead simple. They begin with a specific system state and then perform simple operations in the same order ever time. Something like navigate to amazon.com, add the book Tacit and Explicit Knowledge to your cart, and then verify that the book is in your cart along with all the appropriate information.
A normal user might do something more along the lines of searching for a book, reading the reviews, adding the book to the cart but accidentally adding 2 copies instead of 1, leaving the cart to browse more before returning to the cart to see that the wrong number was added, and finally changing the quantity so that there is only one copy. Even this is probably a simple example that ignores everything a person does while trying to buy a book on Amazon.
Be careful not to get lulled into a false sense of comfort from reports saying all the checks pass. You will probably want to know more before making important decisions like when to ship. The next step is to try a small experiment with your team to see if this style of development can add value. To see how BDD automation framwework can help your team, try TestLeft free for 30 days.