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

 
sitemap

Unable to load book!

The book could not be loaded.

(try again in a couple of minutes)

manning.com homepage
test yourself with a liveTest