BDD: A Discovery example

In our last article, we discussed tasks and activities in BDD. Now it's time to delve a little deeper into the first activity, the Discovery, and provide a practical example. After all, BDD is all about examples!

According to the excellent book "Discovery: Explore behaviour using examples", written by Gáspár Nagy and Seb Rose, mapping user stories to examples (formally written in Gherkin, for example) is done through structured conversations with the client. According to this same book, these conversations should have four main characteristics:

• Collaborative: all participants should actively engage;
• Diverse perspectives: we should have participants from business, development, and testing areas;
• Short: these conversations should be frequent so that feedback and learning are quick;
• Progressive focus: we know the topic of the conversation, but we allow it to delve deeper, always taking notes of all the business rules that arise; and
• Consensus: as a result, we should have examples that are clear to all participants. Any doubts should be resolved.

Let's look at an example starting with the user story. Let's imagine a scenario where software is used to open tickets and our client wants to capture as much information as possible to speed up the service.

At the start of the meeting, the client informs us that tickets are opened via email and are directed to a single queue for initial classification. This is overloading the staff responsible for the initial classification.

Additionally, the emails represent free text where the user can write whatever they want. The big problem is that users often do not provide all the necessary information. As a result, the agents have to return the ticket to the user requesting additional information. This delays the service!

When asked about their goals, the client informs us that they want faster service. They don't want the back-and-forth between the first-level support and the user. They also mention that agents spend a lot of time classifying tickets, which could also be automated.

Based on this piece of information, the team came up with the following user story:

"As a client, I want to open a ticket providing all the necessary information to be attended to as quickly as possible and avoid misunderstandings."        

Delving deeper into the conversation, the client informs us that they have different types of services, each requiring different information. They also mention that filling out long forms is tiring. We need to break them into sections.

Another important observation is that the company has a knowledge base with various tutorials for different situations, which could be presented to the user depending on the situation. This would be self-service with zero response time and zero effort.

Based on these clarifications, let's start creating some practical examples.

1. The user opens a ticket by choosing from various service categories. Their computer is not booting the operating system, so they select "computer support service."

2. The system selects the specification for the chosen service from its database (we have a rule here!).

3. The system presents the first form requesting the necessary details about the ticket.

4. The user fills in the information and submits it. They provide their contact details and location. They also provide the computer ID.

5. The system evaluates the information and, based on the provided details, presents the next screen (another rule here!). This time, the form asks for details about the operating system, the urgency level, and the times when a technician could visit.
(steps 4 and 5 repeat until reaching a final screen)

6. The system presents a summary of the collected information and informs the user that the ticket will be opened with the company.

7. The system classifies the ticket, choosing its destination queue and details such as priority and SLAs. Instead of going to the triage queue, the ticket goes directly to the technical support queue. It is also classified as urgent with a maximum service time of 12 hours. The technician already knows all the details and can visit the location to make the repairs.

8. Then End.        

From this example, we have identified two important rules:

1. We need a database with some specifications for each service. This opens up new use cases for client interaction with this information.
2. The specifications should have ways to decide between different paths based on the data provided by the user.

These questions can be clarified in a second meeting. What remains for the second meeting is the example where a tutorial is presented to a user, allowing them to perform self-service.

But wait a minute, what do these examples have to do with BDD? What about living documentation? And where is the automation? Well, this is just the discovery phase, where we try to build the examples. In the next step, we will carry out the formulation, where the examples will be written in a format that facilitates test automation.