This article discusses how to organise your features and scenarios, starting with grouping features by business functionality, use of tags, and options to store your automation code.
If you’re starting out with BDD, you’ll probably spend some time researching around how best to organise your features and tags. This guide brings together a combination of best practice, our practical experience and how AssertThat’s BDD plugin can simplify the setup.
BDD helps bridge the gap between the technical and business teams, and your example specification will serve multiple purposes. Having the example specification easily accessible enables the team to get the most out of the scenarios, to ensure they can easily:
Identify the key business functions
Identify how features are linked together within business functions
Identify which features/scenarios are in development
Identifying which scenarios are linked to each user story
The technical teams may also be interested in identifying:
Which scenarios are automated vs manually tested
The level of test - Unit, Integration, Acceptance
Which environment the scenario is to be run on
With so many uses, the Features and Scenarios need to be structured such that each user group can easily derive whatever information they require. We’ve learned that each customer has a different setup, and greater emphasis will be put into certain criteria than others. As such, how the features are setup will vary for good reason, however the below points apply.
When you have got a few BDD projects under your belt, you will have a good idea as to how to split up your features for a new project. If you are new to BDD this won’t be clear, and there are many options available to you.
So why do we need to split the features into separate feature files?
Remember the feature files will be used by your team, Developer, Tester, and Business representatives. When someone opens up the features tab in AssertThat, it should be clear what the main areas of functionality are for the product.
Features should be a manageable size and grouped together by business capabilities. These principles will make it easier for the features to be understood by the entire team. If the scenarios are clearly presented and well organised then they will more likely be used and maintained by the entire team.
Features and Scenarios describe the behaviour of the key business functions. They will be developed over the lifetime of the product.
User stories are point in time planning tools to describe a piece of development. When complete, the Features and Scenarios will be updated to reflect the new behaviour of the product, and seldom will the user story be used or referenced again. When the next user story is developed it could change the behaviour of the previous one. What is key is the behaviour as described in the Features.
Tags are a key tool to how the Features are organised. A separate post dedicated to tags can be found here: https://assertthat.atlassian.net/wiki/spaces/DWP/pages/768737311/[email protected]
The Features and Scenarios are used by the entire team and, as such, they can’t be locked away in a repository only accessible by some. At the top of this article we outline how the example specification is central to your agile processes, hence the importance of making them easily accessible. If the scenarios are clearly presented then they will more likely be used and maintained by the entire team.
AssertThat BDD Test Automation plugin is integrated into Jira and, as such, all Features and Scenarios are easily accessible and can be viewed and linked to user stories tickets.
There isn’t a right or wrong way to store your automation code. Everyone’s circumstances will vary and the below section outlines a few considerations
With high level acceptance tests, it’s likely code in multiple repositories will be touched during execution. It therefore doesn’t make sense to align one of the code repositories with the test automation code . Instead, keep the acceptance test code in its own repository, as the scenarios will span different components of the application so won’t have a natural home.
The obvious exception for this is where Gherkin scenarios have been used for unit or API type tests and the scenarios are aligned to a single code repository. In this situation, it makes sense to have the Features and Scenarios in the same repository as the code, as they align only with that repository.