Book Club: Behavior Driven Development – Discovery (Chapter 4)

The following is a chapter summary for “BDD Books – Discovery” by Gaspar Nagy and Seb Rose for an online book club.

The book club is a weekly lunchtime meeting of technology professionals. As a group, the book club selects, reads, and discuss books related to our profession. Participants are uplifted via group discussion of foundational principles & novel innovations. Attendees do not need to read the book to participate.

Background on BDD Discovery

DISCOVERY

“Explore behavior using examples

Written by the creator of SpecFlow and the author of The Cucumber for Java Book, this book provides inside information on how to get the most out of the discovery phase of Behaviour Driven Development (BDD). This practical guide demonstrates good collaboration techniques, illustrated by concrete examples.

This book is written for everyone involved in the specification and delivery of software (including product owners, business analysts, developers, and testers). The book starts by explaining the reasons BDD exists in the first place and describes techniques for getting the most out of collaboration between business and delivery team members.

This is the first in the BDD Books series that will guide you through the entire development process, including specific technical practices needed to successfully drive development using collaboratively-authored specifications and living documentation.”

BDD Discovery

Chapter 4

The prior chapters emphasized the importance of collaboration for BDD to be successful. This chapter demonstrates how BDD can be integrated into the Software Development Lifecycle (SDLC) by describing the approach in more detail. The chapter will answer the following questions:

• “Who should write the scenarios?”
• “Who do we need to participate in the requirement workshops?”
• “Should the testers or the developers automate the scenarios?”

4.1 The BDD Approach

Figure 21 is a simplified approach of BDD. In practice, BDD is more complex and requires several connected activities to be successful.

For each step in the process, please refer to Figure 22.

#1 Pick a User Story

• What: Requirements elicitation and prioritization.
• When: Before the requirement workshop – preferably at least a day in advance.
• Who: Product owner, business analyst, customer, key stakeholders
• Outcome: A candidate user story, scoped with relevant business rules (acceptance criteria). There should be enough detail to allow the development team to explore the scope of the story using concrete examples.

#2 Requirement Workshop

• What: Discuss the user story by focusing on rules and examples.
• When: Regularly throughout the project – we recommend running short workshops several times a week.
• Who: All roles must be represented at this meeting (at least the three amigos), but multiple representatives of each role can attend. Each role representative has their own responsibility and focus.
• Outcome: The candidate story is refined, and is frequently decomposed into smaller stories, each accompanied by a set of rules and examples. The examples should be captured in as light a format as possible, and should not be written using Given/When/Then.

#3 Formulate

• What: Formulate the examples into scenarios.
• When: Before the implementation of the story starts. Best done as the first task of development, but sometimes done as a separate workshop where all scenarios scheduled for the iteration are formulated.
• Who: In the beginning, when the language and style we use to phrase the scenarios is still being established, it is recommended to do it with the entire team. Later, it can be efficiently done by a pair: a developer (or someone who is responsible for the automation) and a tester (or someone who is responsible for quality) as long as their output is actively reviewed by a business representative.
• Outcome: Scenarios added to source control. The language of the scenarios is business readable and consistent.

#4 Review

• What: Review the scenarios to ensure they correctly describe expected business behavior.
• When: Whenever a scenario is written or modified.
• Who: Product owner (and maybe business analyst, customer, key stakeholders).
• Outcome: Confidence that the development team have correctly understood the requirements of the business; the behavior is expressed using appropriate terminology.

#5 Automate

• What: Automate the scenarios by writing test automation code.
• When: Automate scenarios before starting the implementation, following a test driven approach. This way the implementation can be “driven” by the scenarios, so the application will be designed for testability and the development team will have greater focus on real outcomes.
• Who: Developers or test automation experts. When doing pair programming, pairing a developer with a tester works well.
• Outcome: Set of (failing) automated scenarios that can be executed both locally and in continuous integration/delivery/deployment environments.

#6 Implement

• What: Implement the application code to make the automated scenarios pass. Completed through TDD cycle of Red/Green/Refactor.
• When: Implementation starts as soon as the first scenario has been automated, so the implementation is being driven by a failing scenario.
• Who: Developers.
• Outcome: A working application that behaves as specified. This can be verified automatically.

#7 Supplementary Test

• What: Perform manual and other forms of testing, described in test strategy document (e.g., scripted, manual testing, exploratory testing, performance, and security).
• When: As soon as enough is known about the story to begin testing. Scenarios provide a functional breakdown of the user story, so each scenario itself contributes a meaningful part of the application’s behavior. Test preparation can start even earlier.
• Who: Testers – other team members can help with some aspects of testing, but these activities are usually coordinated by testers.
• Outcome: High quality working application; the story is done.

#8 Release

• What: Produce a feature that can be delivered to production. A released product should be used to gather feedback from the users, which can provide input to future development cycles.
• When: At any time that all tests are passing for a feature.
• Who: The development team is responsible for producing the releasable features, but DevOps is usually responsible for delivering the finished feature to production.
• Outcome: An “done” release package.

4.2 BDD in Scrum

In Scrum, work is organized into sprints that are 2-4 week iterations. There are regular workshops that focus on the customer’s requirements throughout each Sprint (backlog refinement, backlog grooming sprint planning preparation, sprint planning) where user stories are prepared.

At the Sprint Planning meeting, the team chooses a few stories to implement in the upcoming sprint.

Once the Sprint is done, the team presents their results in a Sprint Review/Demo and potential process improvements are discussed in the Sprint Retrospective.

Requirement Workshops

In BDD, the team will explore and discover details of stories as part of refinement activities If the Product Owner is available, then they should organize short Example Mapping sessions regularly to replace backlog refinement meetings. Examples will help focus the work on outcomes.

Formulate

Establishing a shared understanding is important, but making the entire team discuss the best way to express a scenario in business language is not efficient.

The best time to formulate the details of scenarios is outside the requirement meetings. Formulation is usually undertaken by a pair, often a developer and a tester.

In some projects, the scenarios have to be formally approved by the product owner or someone else. In these cases, the formulation has to be prioritized and planned in a way that the team does not get blocked.

How scenarios help with the decomposition into tasks:

“In Scrum, stories are usually broken down into tasks. Tasks are work units that represent the design decisions of the team and they are also used to track the daily progress of the team.”

Chapter 4 – BDD in Scrum

Tasks are owned by the development team The tasks are often technical and do not have to be understandable by the Product Owner. However, examples and scenarios should describe the functional breakdown of the story (business readable).

Tasks are aligned to scenarios, which results in several benefits:

• The team will focus on the expected behavior during the implementation.
• Feedback about the story implementation earlier.
• Manual testing can be started before the story is fully implemented.
• The functional progress provides better transparency and hence increases the trust between the development team and the product owner.

4.3 BDD in Lean/Kanban

Kanban optimizes end-to-end delivery (“lead time”) by visualizing the workflow and limiting work in progress (WIP) to be able to detect and fix bottlenecks more easily.

The activities of the BDD approach are realized in user stories, which are the typical work unit tracked on Kanban boards. Example Mapping sessions can be used to feed the input of the development pipeline whenever capacity allows.

For automation implementation, an additional column would be added to the Kanban board. The tasks formulate, automate, implement, review and supplementary test can be seen as a sub-workflow.

4.4 BDD in Distributed Teams

BDD in distributed teams is carried out in the same way as for co-located teams. Good audio-visual facilities and collaborative online tools are essential. Providing information about the scenario implementation status can lead to improved cooperation between developers, testers, and product owners.

Requirement Workshops with Distributed Teams

Modifications are necessary over the use of index cards in Example Mapping. •A remote requirement workshop will still maintain the same standards:

• Focus on rules and examples when discussing the story
• Nominate a facilitator who keeps the meeting going
• Collect results in a format that all team members can understand, so that They can challenge them if necessary
• Capture questions that block the discussion and make them visible to everyone
• Provide an easy way to have an overview of what we have discussed already
• Produce shared notes

There is no online implementation of Example Mapping; however, Google Sheets can be used as an active workspace during the remote requirement workshop.

4.5 BDD in Fixed Scope Projects

“Projects with fixed price, fixed scope, fixed “everything” are definitely not ideal for agile software development, especially when we’re building highly complex, sophisticated and usable applications in a rapidly changing business environment.”

Chapter 4 – BDD in Fixed Scope Projects

Typical fixed scope projects are provided with a detailed specification document that is supposed to describe all the necessary details to provide a cost estimate.

A large portion of work is about understanding the domain, trying to provide solutions for the requirements that satisfy the customer, stay within the scope of the original, contracted specification document, and stay within budget. BDD can help to provide a frame for domain discovery and for documenting the detailed requirement decisions the team makes.

Use Example Mapping to prepare the individual features for development. When a feature is ready for development, the specification document should be used to build an Example Map with all the rules and illustrative examples. The static specification document can be transformed into a continuously validated living document.

4.6 BDD in Regulated Environments

Regulated Environments focus on the following areas:

• Completeness and correctness of the specification
• Coverage provided by the tests and the testing strategy in general
• Evidence that the testing has been performed for a particular version

BDD applies to a regulated environment in the following ways:

• The scenarios are selected initially to be illustrative examples of the specifications. The aim is to ensure consistency and shared understanding across the team.
• The set of scenarios can be extended by further test cases using the same format, to reach the coverage prescribed by the testing strategy.
• The scenarios are business readable and they bring together the specification and the tests. This duality ensures a higher consistency and linkage between these areas.
• The scenarios are strictly versioned, together with the application code.
• BDD tools typically execute scenarios directly and produce a report of the execution result.

Running automated scenarios in this environment will document the expected behavior, describe the tests that verify the behavior, and provide evidence of execution.

4.7 What We Just Learned

BDD is a set of practices that, when combined, can improve the quality of a team’s development process.

BDD integrates with various common development methodologies and team configurations.

With appropriate technology support, BDD can work well for distributed teams, acting as an aid to collaboration.

Series Navigation