Transcripted Summary
The first phase of the textbook BDD process is called the Discovery phase.
In the Discovery phase, we'll focus on gathering examples describing how our software is supposed to behave in order to create a shared understanding and to make sure that everybody playing a role in developing, testing, and releasing software is on the same page with regards to the intended behavior of the software.
Traditionally, a lot of waterfall-style software development projects suffered from misunderstanding and misinterpretation of what the software is supposed to do, with defects and a suboptimal user experience as the result.
The Discovery stage of the BDD process is meant to alleviate that pain by creating a shared understanding of what the software is supposed to do.
There are a number of techniques in the BDD process that can help you create that shared understanding.
Some of the more well-known ones are Specification by Example, Example Mapping, and Feature Mapping. These techniques can be seen as a form of requirements gathering or story refinement.
They are often carried out in what is known in the BDD community as “Three Amigos sessions”, meaning that these sessions are run by at least one person wearing the developer hat, one person with a tester hat, and one “product person,” such as a business analyst or a product owner, or it could even be an end user.
The techniques in the BDD toolbox that we'll typically use in the Discovery stage often focus on using examples.
Now, you might wonder: why examples?
There's a good reason for that; it’s because our brains typically struggle with understanding and reasoning about concepts. We tend to memorize and talk about concrete examples much easier.
With concrete examples, it's also much easier to ensure that the set of examples is complete and to identify gaps in our understanding and in our specifications.
Once we have enough of these examples, our brain is much better able to fill in the gaps and grasp the overall concepts that are illustrated by the examples.
So, here's a high-level description of the Feature that we are going to build throughout the course.
As a loan application evaluator, I want to only approve loan requests that meet our agreed-upon loan amount rules so the risk associated with supplying loans remains within regulatory boundaries.
In other words, we only want to approve loans that meet regulatory standards.
In our case, the development team responsible for developing and releasing this Feature uses Example Mapping in the Discovery stage of the BDD process.
We will not discuss how Example Mapping works in detail in this course, but you can always refer to this link for a detailed description.
Let's have a look at the starting point as well as the outcomes of an Example Mapping session, as that should give you a good idea about what typically happens during such a session.
So, our starting point for the Example Mapping session might look something like this.
We have our story description that we've seen earlier in this video, as well as some additional business rules and requirements that are known beforehand, maybe because these are defined by law or by other regulatory constraints.
The first 3 rules define under what conditions a loan application is approved or denied.
Rule number 4 gives more information about the required monthly down payments for the loan, and the 5th and final rule describes a requirement in the area of user-friendliness.
Now, while these rules are all perfectly valid, they are often not clear enough, not unambiguous enough to be used as a basis for development.
There is still a lot of room for misinterpretation and miscommunication, and this is exactly why techniques like Example Mapping exist. In Example Mapping, you come up with very concrete examples, the more concrete, the better.
These examples illustrate the desired behavior of this Feature.
And typically, in coming up with and discussing examples, the Three Amigos will also identify gaps in the requirements, things that are unclear, and areas where more information is needed.
And sometimes, they might even decide to break up a Feature or a user story into smaller, separate Features or user stories.
After the Example Mapping session has finished, the board that our team is working on to gather and structure the examples might look something like this.
For each of these rules that were defined upfront, we have a number of very concrete examples.
So, we have some examples for the first rule. And we have a couple more examples for the second rule because the second rule is a little bit more complex than the first rule.
We also have a number of very concrete examples for the third rule.
Now, as I said, a possible outcome of an Example Mapping session is that some rules or some parts of a user story might be separated and put into its own user story to be developed separately. And that's exactly what happened with the rule about the monthly down payment and the rule that spoke about the behavior when the loan processor was unavailable.
We now have a complete set of very concrete examples that describe the conditions and the business logic that determines whether or not a loan application is approved, and this is going to be the input for the second stage of the BDD process.
