Author: Dennis de Booij email: dennisdebooij@gmail.com
en andere uitwerkgroep BDD TestNet
Redactie: Eric Spaargaren en Paul Beving
Example Mapping: discovering the details
The subsequent step involved translating the insights gained in the Event Storming session into concrete examples, focussing on the requirements from the perspective of our primary actor – the platform’s customer. Our aim was to clarify and confirm acceptance criteria in an Example Mapping session: another collaborative discussion involving various stakeholders, including customer representatives in the form of the domain experts and the development team represented by the work group members. The conversation is structured with a simple, low-tech method – coloured index cards – to keep the meeting short and productive as shown in the following picture.
Image 6: Photo of the example mapping session
Below you will find one of the examples that was captured on the index cards in this session and then organized into a coherent map. At the top of the table denoted by a yellow index card, is the overarching story. Below the story, represented by blue cards, are one or more rules. Each of these rules is clarified with corresponding examples – often called ‘scenarios’ – that are depicted on green cards. Any unresolved questions were recorded on red cards, earmarked for future discussion to maintain the momentum of the conversation.
Image 7: Digital version of the example mapping sticky notes
At the end of the session, we noted the following:
- The work group members had to refrain from our professional tendency as testers to add ‘negative’ scenarios. This scenario, for example, was not added to the mapping: “The practical assignment submission is not possible before learning module completion”. Although this is definitely something you will want to validate during development and verify during testing, it does not add value to the specification.
- Despite our initial belief that we had identified most unanswered questions in the preceding Event Storming session, the Example Mapping resulted a considerable number of new red cards.
During the discussion we identified a new story from the viewpoint of the platform administrators: “As platform admin, I want to list the learning module/assignment on the physical proof, so that the platform customer is stimulated to complete multiple modules and assignments.”
These observations underscore the iterative nature of achieving a shared understanding. The ongoing discussions in the various formats – Impact Mapping, Event Storming, and Example Mapping – help sieve through the problem space to uncover hidden needs, potential problems and new opportunities that can affect the success of the platform. In the end, the business context will determine whether to explore these discoveries right away to enhance your product, or to park them for now in case ‘time to market’ has priority.
From Discovery to Formulation
In the final step of our BDD journey, we started to flesh out a selection of scenarios that we had identified in the Example Mapping session into specific steps that describe the interaction of a software solution with the people that use it. In such a ‘Specification with Example ’ session (SwE), the desired behaviour of a software feature is captured in a structured document called a ‘feature file’. The examples, or scenarios, outline the anticipated interactions in human-readable format using a domain-specific language . As always, the goal is to facilitate communication and collaboration between the business stakeholders and IT professionals to create a shared understanding of the feature’s requirements and acceptance criteria. Additionally, feature files serve as executable specifications that can be automated to verify and, in part, validate the actual behaviour of the implemented feature against our model of the specifications. Automation tooling can be crucial in providing fast feedback in the software development process.
During the SwE session we found out that we had missed an example in the previous Example Mapping session: “Administrator evaluates a submitted practical assignment”. Furthermore, one of the examples was discarded as offering the physical ribbon option once more after learning module completion could lead to more costs for the platform admins whilst possibly annoying users had already indicated that they did not want to receive physical ribbons. If we had not taken the time to refine these examples, these gaps in insight would have become apparent at a much later point – potentially leading to hasty alignment discussions and rework. This is typical for the SwE process as ‘realistic examples help spot inconsistencies and functional gaps faster than implementation [11].’ Here is the feature file that illustrates the examples in detail:
Feature: Digital or physical ribbons as reward for successfully completed practical assignment
As a platform member
I want proof of a successfully completed learning module
So that I can share my success.
############################ Remarks ###############################
Persona:
- Petra = Paying member of the platform.
- Ally = Administrator of the platform.
Two possible forms payment: yearly subscription or per module with time-limited access.
This feature is related to the module ‘membership registration’ that registers a paying user. This feature is related to the module ‘user preferences’ where the user can opt to receive physical ribbons via the postal services.
#####################################################################
Rule: Practical assignment option only available upon module completion
Scenario: Practical assignment can be submitted upon learning module completion
Given Petra is a paying platform member
When Petra successfully completes the theoretical section of the “Saddle Pads” learning module
Then the platform gives Petra the “Submit practical assignment” option for the learning module “Saddle Pads”
Rule: Proof of completion only made available when a submitted practical assignment has been approved
Scenario: Administrator evaluates a submitted practical assignment Given the platform has given Petra the “Submit practical assignment”-option for the learning module “Saddle Pads”
When Eva submits the practical assignment for the learning module “Saddle Pads”
Then the platforms admin module gives Ally the option to evaluate the practical assignment for the learning module “Saddle Pads” that Petra has submitted
Scenario: Digital proof of completion is awarded upon approval of the practical assignment.
Given Petra has not opted to receive physical proofs of completion in her user preferences
And the platforms admin module has provided Ally the option to evaluate the practical assignment for the learning module “Saddle Pads” that Petra has submitted
When Ally has approved the practical assignment for the learning module “Saddle Pads” that Petra has submitted
Then the platform gives Petra the digital proof of completion “Saddle Pads Ribbon” as proof of completion of the learning module “Saddle Pads”
Scenario: Member with disapproved practical assignment is given the option to retake the practical assignment
Given the platform’s admin module has provided Ally the option to evaluate the practical assignment for the learning module “Saddle Pads” that Petra has submitted
When Ally has disapproved the practical assignment for the learning module “Saddle Pads” that Petra has submitted with the reason “Incorrect positioning of saddle pads.”
Then the platform sends Petra a notification “Failed practical assignment “Saddle Pads”: Incorrect positioning of saddle pads.”
And the platform provides Petra the option to retake the practical assignment for the learning module “Saddle Pads”
Rule: Physical ribbon is only shipped when a member has opted to receive physical proofs of completion
Scenario: Member with approved practical assignment receives a physical proof of completion when the option for ‘physical proof of module completion’ has been previously selected
Given Petra has opted to receive physical proofs of completion in her user preferences
And the platforms admin module has provided Ally the option to evaluate the practical assignment for the learning module “Saddle Pads” that Petra has submitted
When Ally has approved the practical assignment for the learning module “Saddle Pads” that Petra has submitted
Then the platform’s admin module generates the letter “Congratulations on successful completion of Saddle Pads!”
And the platform’s admin module sends Ally a notification “Send Saddle Pads Ribbon to Petra”
Conclusion
In agile software development, where responsiveness and collaboration are vital drivers of success, Behaviour Driven Development (BDD) provides practical and lightweight tools to deal with complex problems, stakeholder alignment and miscommunication challenges. Through structured collaborative sessions, BDD facilitates a shared understanding among stakeholders, ensuring alignment between desired outcomes and delivered solutions.
The case study presented here illustrates BDD’s effectiveness in navigating complex software projects. By engaging with domain experts, the BDD work group of Testnet showcased how BDD can drive innovation and clarity in requirement specification.
From defining project goals through Impact Mapping to uncovering system intricacies via Event Storming and finally formalizing requirements with Example Mapping, each step in the BDD journey contributes to a robust and adaptable development process.
Ultimately, the collaborative efforts culminate in a Specification with Example session, where scenarios are meticulously crafted to capture the desired software behaviour. This not only enhances communication between business stakeholders and IT professionals but also serves as living documentation in the form of executable specifications, ensuring the delivered software aligns closely with stakeholder expectations.
As it was a case study it provides an example of how you can apply BDD practises. When applied in reality within organisations, BDD is a continuous, collaborative way of working to ultimately specify all relevant requirements in your domain and thus create and maintain a single source of truth of what is desired to meet the needs of the business/end-users. By embracing Behaviour Driven Development, software teams can navigate the complexities of agile development with confidence, delivering solutions that meet both business objectives and user needs effectively.
As with any methodology, continuous improvement and critical evaluation is key. To follow up on this article the Testnet work group is currently assessing in which contexts BDD has proven to provide value by exploring scientific research on this topic for real-world metrics or testimonials to demonstrate BDD’s impact on project success rates or customer satisfaction. Additionally, we intend to provide insights into potential challenges when implementing BDD into your organisation.
Source list:
[11] ‘Specification by Example’, Gojk Adzic, page 113
Terug naar deel 1.