Preface: Acceptance Test Engineering Guide

Why We Wrote This Guide

Accepting software is one of the most important decisions for software to take flight and to start delivering value. Yet, there exists little guidance about what this decision should be based on and how to make it effectively.
Over many years in industry and applied research, it was our observation that people often misunderstood the challenges of accepting software, or worse, did not even have a clear notion of who is in charge of acceptance. Many appear not to be aware of the arsenal of practices and tools available to them to address those challenges. This led to disappointments, failed opportunities, broken business relationships, and litigations. There exists a rich body of knowledge on software testing (with notable works by Boris Bezier, Bertrand Meyer, Gerald Weinberg, Cem Kaner, James Bach, Brett Pettichord, Lee Copeland, Mark Fewster, Dorothy Graham, Rex Black, Brian Marick, James Whittaker to name a few), but software acceptance in general, and acceptance testing, in particular, as a process, received no serious, well-reasoned or comprehensive treatment. We set out to fill this gap with two key objectives: devise mental models for thinking about software acceptance and offer actionable guidance on achieving software acceptance.

Who Should Read This Guide

This guide is intended for anyone who is involved in the process of deciding the degree to which a software-intensive product meets the acceptance criteria of those who commissioned its construction. Specifically, this guide will help you if any of the following apply to you:
This guide describes the practices used by people in the preceding roles, regardless what your job title is. If any of them describes your role, you should find something of interest in this guide. Appendix – Reader Personas describes our target audience in more detail. These personas are used to:

Figure1

Figure 1. Reader goals and paths through the guide.

Guide Structure

This guide is structured as a four volume series (Figure 2):


Figure2
Figure 2. Guide Structure.

How to Read This Guide

The way you approach this guide will depend on what role you have and what you want to learn about the process of accepting software. Depending on what you want to do, you will want to apply different strategies.

Get an Overview of Acceptance Practices and Processes

Start by reading Volume I if you want to do any or all of the following:
After reading Volume I, you may want to skim particular practices of interest and the corresponding samples in Volumes II through IV.

Decide Which Acceptance Practices to Use on Your Project

Start by reading Volume I to get an overview of possible practices, and then refer to the thumbnails in Volumes II-IV for specific practices you are considering. Each thumbnail includes a section titled "When to Use It," which includes advice about when the practice should be used, and a section titled "Limitations," which provides guidelines about when the practice should not be applied.

Learn How to Perform a Specific Acceptance Practice

Start by finding a thumbnail in Volumes II-IV if you want to do any of the following:

Get a Template for a Specific Artifact

Start by finding an sample in Volumes II-IV if you want to do any of the following:
Find the example you want in Volumes II-IV, remove the sample information, and populate it appropriately. If you need to review the practice that generated the example, the example lists all the appropriate thumbnails in Volumes II-IV.

Plan the Execution of the Practices on Your Project

Start by reading Volume I to get an overview of how the practices fit together and support each other. In particular, the sections on the Acceptance Process, the Decision-Making Model, and the Doneness Model may be of particular interest. After that, review the specific thumbnails in Volumes II-IV, paying particular attention to the subsection, "Test Life Cycle Applicability" in the section, "When to Use It." Each sample artifact is accompanied by a notation that indicates at what point in the hypothetical project the artifact was produced. Note that some artifacts appear at several points in the project timeline because they evolve over time. If you find your acceptance process takes too long you may find the Streamlining Acceptance Process chapter of Volume I to be helpful.

Find Tools for Acceptance Testing

If you are looking for tools to perform acceptance testing, you may use the guide to explore the available space. Although some of the case studies illustrate using specific tools, remember that the primary focus of this guide is on describing practices.
The choice of tools used while producing this guide should not be interpreted as an endorsement of any tool, nor should it be interpreted as an indication that any tool used is the best one for the job. By the time you read this guide, the tools illustrated in the samples in the guide may have been supplanted by newer and better ones.