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

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 3

This chapter answers the questions: “Are examples really enough to specify a feature? How many examples do we need to specify a feature?”

3.1 How Hard is Concrete?

Outcome: description of the state of the system after the user or system behavior has taken place. It should contain enough detail to measure the behavior against expectations.

Action: the event that causes the behavior to take place. It might be some action by a user, the system, a scheduled job, or any other stimulus that can cause the system to react.

Context: describes the state of the system before the action takes place.

3.2 Is All That Concrete Essential?

Rules are generic expressions of how the system ought to behave – they each cover lots of possible situations. An example expresses a single situation that illustrates an application of a rule. The purpose of the example is to clarify a rule; each example must be specific and precise.

Each example illustrates a single rule, and should only mention concrete data that is directly related to the behavior being illustrated.

Getting the right level of detail is not the primary concern – inessential detail should be removed later when examples are formatted as scenarios.

3.3 How Many Examples Do We Need?

All possible states cannot be reasonably captured in Examples. A balance must be achieved between Examples and Business Rules.

The team determined that the delivery address can’t be changed once an order has moved beyond the “waiting for pickup” state. The team resolved the misunderstanding by using examples. Please refer to Figure 17. A happy middle ground must be reached in describing enough examples to deliver the feature and writing too many features for a given business rule that preclude efficient delivery of the software.

3.4 Why Stop Now?

“Catching all implementation mistakes will be important, but during the discovery phase our focus is on the requirements: we would like to prevent bugs from ever happening.”

Chapter 3 – Why Stop Now?

The Examples demonstrate the development team understands what they are being asked to do and that the business understands what they’re asking for.

“When we start considering the exhaustive exploration of all possible combinations, we have moved away from understanding the requirements into the realm of software testing. When the examples start to address concerns that the product owner is not interested in, it’s time for the facilitator to bring the discussion back on track.”

Chapter 3 – Why Stop Now?

Good coverage for test cases is still important, however this is an activity outside the requirement workshop. The intent of the workshop is engage the product owner and the team.

3.5 Rules vs. Examples

Are examples alone sufficient to specify the functionality of an application? It is not always possible to “reverse engineer” the rules from the examples. Both rules and examples are needed to document the expected behavior of the system.

“The rules provide the concise, abstract description, and the examples provide precise, concrete illustrations of them.”

Chapter 3 – Rules vs. Examples

Why “Specification by Example”? The emphasis is on the use of examples to support a specification by making it harder for the rules to be misinterpreted.

Rules and examples are not the only way to specify the behavior of software. Other tools complement them, such as: definitions, model diagrams, formulas, and glossaries.

3.6 My Example Illustrates Multiple Rules!

Try to come up with Examples that illustrate a single rule. Focusing on a rule and utilizing it are two different things. Consider whether the example utilizes the rules, focuses on the rule, and/or illustrates the rule.

If an example illustrates multiple rules, then split the example into several that each focus on a single rule.

3.7 The Bigger Picture

Short, focused examples illustrate the behavior of a single rule, but the overview of the whole system behavior is missed.

Leverage wireframes, page-flows, box-and-arrow diagrams, and other tools to illustrate the application behavior.

3.8 What We Just Learned

The requirement workshop is an excellent place discuss the understanding of the requirements. Creating concrete examples that illustrate the rules are challenging.

Examples on their own are not sufficient; rules should be documented as well. An Example is comprised of context, action, and outcome.

Examples should illustrate a single rule and contain only data essential to understand the behavior of the rule.

Series Navigation