Getting Started with BDD (Part 2)

In the first part of the post Getting started with BDD, I’ve explained the CULTURAL SHIFT it requires to adopt BDD. In this second post I want to get one step further and share a couple of good practices that will enable you to scale this practice.

Use a consistent business terminology to design your scenarios

After writing your first BDD scenarios using the Gherkin syntax, you’ll be under the impression that it’s easy. But the first pitfall will come soon. Be careful of the dark side.

Come to dark side of maintenance

The more scenarios you have the more difficult it will be to keep maintenance easy. And complexity is not linear but exponential.

So first rule is to keep terminology consistent when writing scenarios.

I log in“, “I sign in“, “I sign in to the application” may have exactly the same intent but they are written differently. The thing is when you’ll have to modify these steps or automate them, it’ll become exponentially complicated.

That’s the reason why Hiptest BDD platform provides autocomplete feature. That enables the team to reuse existing steps and terminology instead of creating new steps and duplications. And this is even more relevant when you have a distributed team.

Full scenario on Hiptest

Refactor your tests continuously

After years of practice, I’ve realized that this business terminology, the steps you reuse across multiple scenarios are subject to constant modifications. So basically you don’t start your project by defining all the steps you’ll use to describe your scenarios & examples. This is defined progressively and changes continuously. Let’s take 2 simple examples

Your start writing your first 10 scenarios starting by:

Given I sign in to the application

And at some point you’ll need to add a parameter “provider” (provider being a Google, LinkedIn or Github account):

Given I sign in to the application with my “provider” account

What happens to the 10 existing scenarios? Answer for a developer is damn simple: refactor them using an IDE. But what about business users, product owners that are supposed to write these scenarios? Hiptest platform enables you to do this kind of refactoring without requiring any technical skill. Just modify the step and all the scenarios using it will be instantly modified.

Another interesting use case with refactoring relates to the level of abstraction. We constantly deal with this when writing scenarios. Am I describing the business behavior, not implementation details? When a sceanario is too close to the implementation, the intent becomes more difficult to understand.

Here are 2 samples. Which one is the easiest to understand and share between all the project stakeholder?

Level of abstraction

The second one is more synthetic and focused on the behavior. To transform the first scenario to the second one, you can apply a useful refactoring technique: promote a group of steps into a step of higher level.

Refactoring to encapsulate steps

This way you refactor continuously your scenarios and make them more readable while keeping maintenance easier 🙂

Automate using a layered approach

When it comes to automate your scenarios make sure you have a layered approach that scales over the time. I’ve already written a post dedicated to automation at scale and describe the common pitfalls. Integration with the CI process is also key to ensure quality of the the delivery pipeline.

Behavior driven development workflow

Typical BDD workflow with Jira & Hiptest 

Keep one single repository for manual and automated scripts

Not all scripts should be automated and for different reasons: maturity of the feature to be developed, complexity of the testing environment… It’s a matter of return on investment. So teams have to manage both manual scripts and automated ones.

A scenario can be first executed manually as part of the current sprint and then be automated and added to the regression suite. The key thing here is to keep one single place for all your scenarios. And the same test, that represents a specification of your application can be executed in different ways. When you change a step it impacts not only a manual test run but also the automated one

Scripts are generated in several frameworks

With Hiptest the same scenario is used to generate script for manual test run as well as script for any test automation framework. So they are always in sync. You have one single source of truth.

ENJOY BDD!

 

Get started for free - Hiptest


8 thoughts on “Getting Started with BDD (Part 2)

  1. How do I change the scripts (the parts that read “Raise Implementation Error” in the Ruby/RSpec screen to generate my automated test that goes back into my software? Second, What if my project is not part of any sprint in Jira? How do I link it to my project without creating a user story in Jira?
    Thank you for answering.

    Like

    1. Hello, you should replace the “Raise Implementation Error” by your own ruby code that interacts with your tested application. You can find examples in Hiptest publisher samples with Ruby/Rspec and more particularly in the actionwords.rb file.

      Your project in Jira doesn’t need to be a part of a sprint. You can link a Hiptest scenario to any kind of Jira issues.
      Regards

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s