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.
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.
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?
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.
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 delivery pipeline.
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
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!
