Chapter 6. The life cycle of executable specifications

 

This chapter covers

  • Working with an executable specification throughout its life cycle
  • Understanding requirements’ precision level
  • Using examples in different development phases
  • Understanding what happens after implementation

In its original meaning in systems theory, feedback is the exchange of data about how one part of a system is working—with the understanding that one part affects all others in the system—so that if any part heads off course, it can be changed for the better. In SBE, a specification suite is the system, every executable specification is a part of that system, and the delivery team is the recipient of the feedback.

As anyone who works in a corporate environment knows, there are two kinds of feedback:

  • Supporting that lets people know they’re doing their job well
  • Critiquing that’s meant to correct the current course of action

The same rules apply to the systems of feedback in SBE. Back in 2003, Brian Marick wrote a series of blog posts about the concept of an agile testing matrix.[1] The series is also one of the oldest articles about modern testing methods I know of that suggested dropping the name tests and replacing it with examples for business-facing testing.

1 See Brian Marick, “My Agile Testing Project,” on his blog, “Exploration Through Example,” August 21, 2003, http://mng.bz/TkO1.

6.1. End-to-end overview of the process

6.2. Understanding business goals

6.3. Analyzing requirements with examples

6.4. Deriving scenarios from examples

6.5. Refining scenarios

6.6. Iterating specifications over time

6.7. Summary