Acceptance tests are defined in this book as the test created by the customer in collaboration with the developer and the tester prior to implementation. They are not the traditional user acceptance tests performed after implementation. Although acceptance tests can be used at different development stages, Ken Pugh proposes mainly in this book an approach where all project stakeholders will collaborate to create tests that validate business requirements.
The book is clearly written and easy to read. At the end of each chapter, a summary proposes the main points discussed. The author proposes a lot of practical examples and case studies that help to apply the concepts discussed to real cases. Some chapters are only focused on the “how to” aspect of Acceptance Test-Driven Development (ATDD) and an appendix shows how to implement it with different tools like Fit or Cucumber. As the book insists about the collaboration between the users, developers and testers, I can recommend it not only to software testers in Agile teams, but to all project team members that want to improve their communication with end users and achieve a better understanding of requirements.
Reference: “Lean-Agile Acceptance Test-Driven Development”, Ken Pugh, Addison-Wesley, 332 pages, IBSN 978-0-321-71408-4
Quotes
Developing software with testable requirements is the theme of this book. A testable requirement is one with an acceptance test. Acceptance tests drive the development of the software. As many development groups have experienced, creating acceptance tests prior to implementing requirements decreases defects and improves productivity. (See the Epilogue for examples.) A triad — the customer / business analyst, developer, and tester — collaborates on producing these tests to clarify what is to be done. In creating a high-quality product, ATDD is as much about this clarification as it is about the actual testing.
I emphasize acceptance tests as customer-developer-tester communication. If you don’t have an acceptance test, you have nothing to automate.
If a requirement does not have a test, it is not yet demonstrated to be a testable requirement. If you cannot test that a requirement has been fulfilled, how do you know when it has been met?
Tests can be made more maintanable by separating what appears to the user from the logic in the underlying business model.
If there are no acceptance tests for the portion of a system that needs no change, create acceptance tests before making the change.