Silvio Cacace/ Menno Pot  15-06-2023

Onze collega Silvio Cacace heeft zijn jarenlange ervaring in het hele testproces gebruikt om de tool TestCompass te ontwikkelen.
We kennen allemaal de shift-left wens: eerder dingen testen zodat fouten in designs en specificaties al gevonden worden, nog voor ze geprogrammeerd worden. Hoe eerder in het proces je fouten vindt, des te goedkoper zijn ze om op te lossen.
TestCompass helpt je om middels een model in een vroeg stadium het gesprek aan te gaan om zo de diepere details van de requirements te vinden. Zo kan er snel achterhaald worden welke requirements er nog missen of misschien zelfs niet goed zijn.
En zodra het beeld compleet in TestCompass zit, kun je met één druk op de knop alle gewenste testcases genereren, op basis van een geselecteerde testcoverage.
Silvio heeft dit principe omgetoverd tot early Model Based Testing (eMBT).

TestCompass blijft in ontwikkeling. Sinds kort ondersteunt het de BDD fases Discovery en Formulation.
Onderstaand een verdere uitleg van Silvio over deze toevoegingen.

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.compasstestservices.
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 (figure 1) and a Feature map (figure 2) 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 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 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
documented.

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

And what about the Gherkin feature files, which are a common delivery of this phase? Well, after the
Example map or Feature map in 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
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 in figure 4 an example of the automatically generated Gherkin feature file with 3 scenarios
from TestCompass based on the selected requirements coverage form ‘Path Coverage’.

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-foragile-
teams/