Develop BDD Mindset:
The most important thing before you dive into writing a feature file is to develop a Behavior Driven Mindset. Without BDD mindset, people fall into writing feature files that are like traditional procedure-driven functional tests with step-by-step instructions. Writing long scenarios with lots of incidental details ruins a good story. But at the same time the scenario shouldn’t be too vague by being too abstract & not containing any details at all.
Don’t create feature file in isolation.
Getting the shared common understanding about the feature is the key element while writing feature file and should not be neglected. Feature files written by team member (that can be a BA or DEV or QA) in isolation will not represent a common understanding and will miss the important input from other stakeholders. If such scenarios are written by DEV, it will be too technical for others to understand or if written by only BA or QA these scenarios may tend to be harder to automate. The scenarios which are discussed by a trio of Dev-QA-BA will result in feature files with true BDD essence.
Watch out your style of writing a feature file:
There are 2 styles of writing a feature files.
- Imperative Style
- Declarative Style
Writing step by step instructions and too many details in a feature file results in imperative style of writing where user gets lost in the details and true objective of writing a feature file is left behind. Such files become too big, fragile and difficult to maintain.
Declarative style of writing a feature file is concise and contains only the information that is directly related to the story/scenario. Such feature files are easy to understand and quickly identify any missing requirements.
This often results in below question:
- Q: How do you go about avoiding the incidentals in your story and yet having these necessary preliminary steps for the scripts?
- A: You should hide them in the step definitions or the page objects.
Explore application behavior through effective scenarios
Each scenario should cover a small functional aspect about the system under test. Don’t test more than one outcome in single scenario as it will make it difficult to identify the issue if the scenario fails. All Scenario should run independently without any dependencies on other scenarios.
Also use Scenarios to explore edge cases and different paths through a feature.
Don’t write automated web site for each possible UI scenario
As User interfaces tend to change much faster than the business logic, it can lead to fragile scenarios & failing tests. To write effective automated web tests, you should know what an ideal candidate for automation is and what is not.
Thomas Sundberg, a seasoned BDD practitioner in Sweden, refers to the agile testing pyramid, and argues that BDD should be used in all places where the business has reason to have opinions about the behaviour. He prefers to focus on integration tests using BDD and as little as possible through the UI.
Some recommended books that will go a long way with you when you start your BDD journey
BDD in Action by John Ferguson Smart
The Cucumber Book by Aslak Hellesøy and Matt Wynne
Cucumber Cookbook by Shankar Garg
Some good resources that you should refer before you start writing feature files. It will help you see the things in right context.