BDD requirements discovery practices supported by TestCompass

26 May

BDD requirements discovery practices supported by TestCompass

Often there appears to be confusion about the concept of Behavior Driven Development (BDD) and far too often BDD is seen as a testing approach. Is this maybe because BDD grew from a response to Test Driven Development (TDD), as explained by BDD pioneer Daniel Terhorst-North?

Although there may be misunderstandings regarding the concept of BDD, this blog does not intend to delve deeply into the complete concept of BDD or provide a comprehensive guide on how to perform BDD correctly. Numerous other blogs have already extensively covered these topics. However, for the purpose of this blog, it is important to at least acknowledge that BDD emphasizes the importance of collaboration between developers, testers, and business stakeholders. It centers around creating a common language that is easily understood by everyone involved, to get a deeply shared understanding of the requirements.

TestCompass

In this blog we explore how the collaborative modeling tool TestCompass, in addition to the early Model Based Testing (eMBT) approach (see our other blog https://www.compass-testservices.com/embt-with-testcompass-in-practice), supports BDD in a very easy to use way. And specifically for the BDD phases Discovery and Formulation. Therefore we will take a closer look how to perform the BDD requirements Discovery practices ‘Example mapping’ and ‘Feature mapping’ (known as 3-amigos sessions) in TestCompass and how to turn the results (concrete examples) of these Discovery practices automatically into business readable language (as Gherkin feature files), in the Formulation phase.

As described in the intro of this blog, Behavior-Driven Development (BDD) is a powerful approach to software development that emphasizes collaboration and communication between all stakeholders (business and technical). However, executing the 3 different phases of BDD (Discovery, Formulation and Automation) can be challenging. Fortunately, there are tools and practices available to help teams execute these BDD phases more effectively.

TestCompass is such a tool, which can help you streamline, simplify and automate the BDD phases Discovery and Formulation.

Discovery

In the BDD phase Discovery, we need to answer the question “What could it do?” and collaboration between business stakeholders, developers and testers is essential here. The goal of this phase is to ensure that everyone is on the same page regarding the requirements. To facilitate this collaboration, often workshops or meetings are hold, like ‘Example mapping’ and ‘Feature mapping’ (also known as requirements discovery workshops and 3-amigos sessions). In this meeting, a group of individuals (including at least a business stakeholder, developer and tester) convene to discuss a user story and document specific examples on index cards or sticky notes that serve as illustrations for that user story. These examples, typically associated with a particular business rule, generally comprise of the context, action, and outcome, effectively demonstrating the behavior described by the story.

TestCompass can support these requirements discovery practices, ‘Example mapping’ and ‘Feature mapping’, by the possibility to model out the Example map and Feature map by simply drag and drop different used colored sticky notes onto the canvas. For ‘Example mapping’ normally yellow sticky notes for the story, blue for the rules, green for the examples and red sticky notes for the questions that arise, are being used. In `Feature mapping’ normally yellow sticky notes for the story, blue for rules, green for examples, yellow for the steps and purple for the consequences are used. Also here red sticky notes for the questions that arise.

See below an example of an Example map and a Feature map modelled in TestCompass.

Example map 'Reservation charges'

Feature map 'Refund'

Modeling the Example map or Feature map directly in TestCompass is very easy and works really intuitive. It has many advantages over running a manual requirements discovery session. Besides the fact that all information from the sessions is automatically documented and saved in TestCompass, there are many other advantages. For e.g. in TestCompass it is easy to make changes or add extra comments to the Example map or Feature map. But also better visibility is an advantage, especially when the session is done online. And better visibility makes it easier to share and discuss ideas and examples. Another advantage is reusability. TestCompass allows the sessions to be reused for similar project or features. This can save time and effort in future projects and help to ensure consistency across different teams and projects. And do not forget a lower chance of making typos in the next phase Formulation, where the examples will be described in a formalized language. In TestCompass we can re-use a lot of the text from the Example map or Feature map (see next phase Formulation).

Formulation

The BDD phase Formulation will start once the ‘Example mapping’ or ‘Feature mapping’ session in the BDD phase Discovery, is completely done and the goal of this phase – a shared understanding – has been achieved. In this phase we need to answer the question “What should it do?”. Now all the examples (and counter examples) created in the Discovery phase will be turned into a more proper and formalized language. And often this is done by the so called ‘Gherkin-gang’ by describing all the examples in Gherkin syntax (Given-When-Then format), so that they later can be used as executable tests.

During the formulation phase, TestCompass can help to convert the Example map or Feature map into a graphical model with a high level of abstraction and thus readable for both business stakeholders as technical stakeholders. This promotes the ability to have the graphical model reviewed within the team and ensure that all results from the requirements discovery practice have been properly interpreted and worked out in the graphical model and there is a deep shared understanding of what needs to be built (requirements). After all, a graphical representation is still much easier to read and to understand than a text, even if this text is plain English. It is also possible to add extra comments or new upcoming questions in the model itself by using a special balloon node. This makes the result of this phase even more readable and well documented.

See below an example of how the first business rule of the Example map ‘Reservation charges’ has been converted to a graphical model in TestCompass. For clarity, the relevant part of the Example map is also shown on the left side.

And what about the Gherkin feature files, which are a common delivery of this phase? Well, after the Example map or Feature map is converted to a graphical model in TestCompass and has been reviewed, the Gherkin feature files can be automatically generated from the model. This is of course a great advantage. You no longer have to write out all the Gherkin feature files by hand and thus less time consuming and less chance of making writing errors. Furthermore, within TestCompass it is possible to select a requirements coverage form (from weak to strong) before the Gherkin feature files are generated. With this, the generated Gherkin feature files are related to the pre-selected coverage and therefore all the different scenarios in the Gherkin feature file are coverage based.

It is also possible to include the background in the graphical model. In addition, you can include any examples and tables in the details of the model. These are then automatically included in the automatically generated Gherkin feature file (outline scenarios).

See below an example of the automatically generated Gherkin feature file with 3 scenarios from TestCompass. This is based on the selected requirements coverage form ‘Path Coverage’. Also included is a general section containing the date, name of the project and model and the coverage used for generating the Gherkin feature file.

Of course, it is always possible that later, one or more changes may need to be made to the requirements, and as a result, the Example map or Feature map may also require updating. This can potentially impact the scenarios in the previously created Gherkin feature files. However, in TestCompass, implementing such changes is a breeze, as you can effortlessly incorporate them and instantly generate the Gherkin feature files automatically once again. This means you don’t have to manually update existing Gherkin feature files or create new ones from scratch.

A significant additional advantage provided by TestCompass is its ability to perform an Impact analysis. This means that when a change occurs, TestCompass automatically generates a comprehensive overview of the scenarios from the related Gherkin feature files, highlighting their new status, such as updated, unchanged, removed, and added. With this feature in TestCompass, it becomes entirely transparent which scenarios of the previously generated Gherkin feature file were affected by the change and in what manner. This allows for a clear understanding of the precise impact brought about by the change in question.

To summarize, some of the key advantages of using TestCompass for the Discovery and Formulation phases of BDD:

Streamlined collaboration: TestCompass facilitates communication and collaboration between business stakeholders, developers, and testers. It provides a platform where everyone can work together to create a common language that is easy to understand and interpret.
Automated documentation: TestCompass automatically documents all information from the requirements discovery sessions. This means that there is no need to manually record or transcribe the results, saving time and effort.
Better visibility: TestCompass provides better visibility of the requirements discovery and formulation processes. This makes it easier to share and discuss ideas and examples, especially when the session is done online.
Reusability: TestCompass allows sessions to be reused for similar projects or features. This saves time and effort in future projects and helps to ensure consistency across different teams and projects.
Lower chance of errors: By using TestCompass, there is a lower chance of making typos or other errors in the next phase of BDD formulation, where the examples will be described in a formalized language.
Graphical representation: TestCompass can convert the example map or feature map into a graphical model with a high level of abstraction. This makes it easier for both business stakeholders and technical stakeholders to understand and review the requirements.
Automatically generate coverage-based Gherkin feature files directly from the graphical model.
Automated Impact analysis after a change in the requirements. Provides an overview which previously generated Gherkin feature files were affected by the change and in what manner.

Overall, TestCompass is a powerful collaborative modeling tool that in addition to the early Model Based Testing (eMBT) approach, can support the Discovery and Formulation phases of BDD in a very easy to use and intuitive way. TestCompass can be an excellent choice for organizations that are looking to adopt a BDD approach and improve collaboration and communication between all stakeholders involved in the software development process.

Silvio Cacace, founder TestCompass

For more information about ‘Example mapping’, I kindly refer to https://cucumber.io/blog/bdd/example-mapping-introduction/

For more information about ‘Feature mapping’, I kindly refer to https://johnfergusonsmart.com/feature-mapping-a-lightweight-requirements-discovery-practice-for-agile-teams/

BDD requirements discovery practices supported by TestCompass

26 May