15 Living documentation and release evidence

In this chapter, we’ll focus on an important part of BDD that you need to understand if you’re to get the most out of whatever BDD strategy you adopt. You’ve seen how BDD encourages teams to express requirements in terms of executable specifications that can be run in the form of automated tests. These executable specifications become the definitive reference (often referred to as the “source of truth”) for the current set of application requirements. The definitive form of these executable specifications is generally source code, so they fit neatly into the overall development process and drive the automated tests. The reports generated by the automated tests refer back to the original executable specifications. These reports, which combine the original specifications, acceptance criteria, and test results, are what we call living documentation.

15.1 Living Documentation: a high-level view

15.2 Reporting on feature readiness and feature coverage

15.2.1 Feature readiness: what features are ready to deliver

15.2.2 Feature coverage: what requirements have been built

15.3 Integrating a digital product backlog

15.4 Leveraging product backlog tools for better collaboration

15.5 Organizing the living documentation

15.5.1 Organizing living documentation by high-level requirements

15.5.2 Organizing living documentation using tags

15.5.3 Living Documentation for release reporting

15.6 Low Level Living Documentation

15.6.1 Unit tests as living documentation

15.7 Living Documentation for Legacy Applications

15.8 Summary