A continuing challenge in software development is ensuring that an application delivers the right functionality as well as a great user experience. Over the years, development teams have adopted various approaches to solving this challenge. A majority of organizations have moved – or are in the process of moving – from a structured “waterfall” approach with a major emphasis on requirements definition to a more agile approach where user representatives provide regular input to short, iterative development cycles. Continuing this trend, behaviour-driven development (BDD) is becoming increasingly important as a solution that brings users, product owners, and testers into agreement about the product requirements.
In BDD, the development team, which includes user representatives and testers, creates user scenarios in simple, declarative statements. For example, a user scenario in an online store payment system might read something like the following:
FEATURE: Select a payment type
SCENARIO:
GIVEN I am logged in to my account, which has at least one saved credit card
WHEN I navigate to the payment field
THEN I should see all of my saved payment options
AND can select one with a single click
This syntax is formal enough to communicate requirements clearly, while being understandable to everyone on the team, regardless of programming experience. The example above uses Gherkin syntax, which is not required to practice BDD, but which does make it possible to build automated tests directly from the BDD scenarios. Requirements specified in Gherkin syntax are saved to .feature files, which can be automated using a tool such as Cucumber or SpecFlow. To see how Ranorex Studio integrates with SpecFlow, check out our blog article How to Use Ranorex Studio in your BDD process.
But, as test automation expert and author Jeff Langr explained in a recent blog post, “In BDD, automation is not the primary goal. Yes, automation may be essential if you want to do continuous delivery, and yes, automation is where you see great success with BDD. But the first goal is to understand how to use BDD as a means of getting on the same page. And if you can’t get that far, automation isn’t going to help you much anyway.”
Like everything worthwhile, adopting BDD has its challenges. Changing processes is never easy, as this usually requires a corresponding culture change, which is particularly difficult for large organizations and complex projects. To hear how to overcome the leading challenges to implementing BDD from Jeff Langr, and have the opportunity to ask him your BDD implementation questions, register for a free, live webinar “Breaking Through the Barriers to BDD”, on the 14th of June at 12:00 PM EST, 16:00 GMT.
