Foreword

I figure it's my job in a foreword to tell you why I think a book is worth reading. Often this involves setting context, placing the book with respect to historical or social or technical trends. Sometimes I point out how the authors have been too humble in their presentation. Sometimes I talk about what I've learned from a book. In this case I am able to use all three techniques.

Technologists have spent the last half century swinging on a pendulum between being lowly serfs obeying the commands of their business masters and acting as high priests at the altar of Computing. The last decade has seen the first tentative steps towards a more realistic and sustainable position of partnership with business sponsors and users. The new emphasis on acceptance testing is evidence that this trend continues.

I say "emphasis" because acceptance testing is not new. Ever since the first user told the first programmer "That's not quite right," acceptance testing has been part of the development workflow. Since those focused on technology and those focused on business bring different values, expectations, and vocabulary, some misunderstanding is inevitable. What's that Professor Heisenberg? Oh, yes, thanks for the reminder. The appearance of a system automatically (it seems) changes its requirements. Between these factors, acceptance testing is part of effective development.

Legitimately shifting requirements have a profound effect on the timing, role, and techniques of acceptance testing. One of the trends in development over the past decade is that testing takes place sooner and more frequently in development. Even with the bulk of acceptance testing shifted to just in advance of development (Acceptance Test Driven Development), someone still needs to be listening for "Thanks for that, but what I really want is..."

One implication of the growing frequency of acceptance testing is the need for automation of repetitive testing tasks. This is not a job for testers alone. To increase the rate of feedback, programmers must make their systems more testable. Automation frees resources for higher-leveraged manual testing.

One thing I appreciated in this book was the consistent connection between acceptance testing and risk management. Acceptance testing is worthwhile for the value it adds to development: increased probability of customer satisfaction, reduced risk of errors, and better tracking of progress. The image of risk management as a way to buy reaction time will stick with me. Early incremental acceptance tests can be the scouts sent out to inform the army of trouble to come.

One of the strengths of this series of books is the variety of formats for the information. The first volume presents the intellectual foundations of acceptance testing. Remaining volumes present concrete practices that work within that framework, a menu of "Here's techniques that have worked" as well as a worked example for those looking to understand acceptance testing in context.

I'll close by pointing out where I think Grigori, Gerard, and Jon’s humility got the better of them. What if software development was turned on its head? What if the whole process worked backwards from "The customer is delighted with the system"? Before you could expect to hear a statement like that, you'd need to spend a lot of time testing the system in realistic environments. You'd need to make sure all the easily understood features worked as expected. Acceptance testing and acceptance test-driven development can encourage this. Novel features and interactions of features would also need to work in a sensible way, another goal acceptance testing can contribute to. When those "Great, but what I'd really like to see is..." moments happen, incremental acceptance testing can help them occur early enough that the whole team can respond.

As the concrete manifestation of the dialog between business and technology, acceptance testing can play a central role in software development. Here in your hands is a book that distills years of experience with acceptance testing, a bag of ideas you can reach into again and again as you travel towards: "The customer is delighted with the system..."

Kent Beck
June 2009