TL;DR

It was time for the second workshop, Breaking Down Problems With Example Mapping, held by Gaspar Nagy.

I met Gaspar at Testival 2019, where we invited him to hold the closing keynote. Gaspar is a de facto BDD evangelist, and also a brilliant person. By brilliant, I mean that I enjoyed our conversations on various software testing topics. If you have a chance, I recommend that you invite him to give one of his workshops at your company or conference.

From Gaspar, I finally got what BDD is all about. It is not Cucumber files and automation. It is about teamwork doing example mapping.

The workshop started by forming groups of three participants. Each group member should give an example of a recent software bug that participants encountered:

1. Upload of many files caused Browser to become unresponsive
2. A user story that was not implemented in a sprint
3. VISA Prepaid Debit card issued in Croatia that was not accepted on some POS machines in the Netherlands. Some of those places did not accept cash either.

So what is BDD all about? We first discover what needs to be implemented, then we formulate that implementation, and in the end, we automate to have a working example of application.

We start with User Story. In the user story, the product owner communicates to the team what needs to be implemented. But this is just a draft, starting point for team communication. Real requirements are Rules that are derived from a User Story. Based on Rules, we create examples of User Story. Examples are like tests, but not all the tests. Examples enable team communication and help to clear out all team Assumptions about User Story Rules. Trivial rules usually hide bugs.

We were grouped in teams of five members. We had a product owner, facilitator wrote on a white sheet, and the rest of the members were a team. The first exercise was to write four rules for the Change ATM PIN user story. We had four minutes for this exercise. The first rule was already provided, the other four are my group work:

1. The two new PINs must be the same
2. There is Bank Label On ATM
3. Main menu option for Change PIN
4. A message with instruction on how to change the PIN
5. Three input fields that are enabled for input with labels

The second exercise  was to do the example mapping for the following change pin rules:

1. The new PIN must contain at least two different digits
2. The user should be able to cancel the transaction any time

We hit assumption conflict immediately with the first rule :). Two different digits in a new PIN or different compared to old PIN? Product Owner was a judge, and we decided on the latter option. Each example started with a summary heading. We learned Friends naming convention:

The one where …

Our first example for the first rule was:

The one where one digit differs.

PIN is 1234

Enter 4567 x2

Confirm

Success message.

Second was:

The one where new PIN reverses old one.

PIN is 1234

Enter 4321 x2

Confirm

Fail message.

The fun started with the second rule. For that, we first draw a timing diagram (bottom of the first picture) to align assumptions at which point action could be canceled. And then, time was up! We had only four examples.

Two groups with most examples received a book where you can deepen your example mapping knowledge:

Remember:

Discovered examples are not all possible tests, and they should not be. We do not document all the tests. Examples are the assumption discovery tool.