Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration
Within the framework of Acceptance Test-Driven-Development (ATDD), customers, developers, and testers collaborate to create acceptance tests that thoroughly describe how software should work from the customer’s viewpoint. By tightening the links between customers and agile teams, ATDD can significantly improve both software quality and developer productivity.
This is the first start-to-finish, real-world guide to ATDD for every agile project participant. Leading agile consultant Ken Pugh begins with a dialogue among a customer, developer, and tester, explaining the “what, why, where, when, and how” of ATDD and illuminating the experience of participating in it.
Review By: Mark Cole
12/29/2011
One of the most interesting books I have ever read is Gottlob Frege's The Foundations of Arithmetic on the logical proof of mathematics. Frege proves, using logic alone, that 2+2=4. What if you could do the same thing to prove a software program? What if you could write a recipe on how to verify, design, and document a computer program all in one shot? This book does not totally give us such a recipe, but it gives important hints that may help us get there.
Lean-Agile Acceptance Test-Driven Development by Ken Pugh is a great book that I was able to apply to the work that I am doing. It shows the importance of clear communication between the triad—the customer, tester, and developer. It gives a methodology to forming acceptance tests before the first line of code is written. It gives you four different ways to implement these acceptance tests: using a manual test script, using a test user interface, using a framework xUnit test, and using automated acceptance tests while the code is being written. It also gives a non-trivial example along with variant test studies.
I have two complaints. One is that the non-trivial example does not have a deliverable solution as one of the appendixes. As a reviewer, I would like to see the complete set of acceptance tests and the work and source code that the developer wrote. The book tells you how to write acceptance tests that should cover every single line of code that was developed for the given application, but it doesn't provide the complete solution. It stops with only a handful of acceptance tests, but I can think of more that should be included.
My second complaint is that as an automation tester I would appreciate step-by-step instructions, as well as pitfalls and benefits, to implementation number four, automatic acceptance tests. The book is very good about providing step-by-step instructions on creating the charter, writing features, creating user stories, creating scenarios, and writing acceptance tests, but I want instructions on how to take those acceptance tests, press a button, and get a report that all the tests passed or failed. There is an appendix about this that says, "There's more than one way to skin a cat," and provides tables using FIT, SLIM, and ROBOT and links to other test frameworks. So, something is provided in this direction, but the explanations are not as clear as they could have been.
I did learn why clear communication is crucial to the lean and agile process. My seminal programming experience was writing Macintosh software in my parent's house using a program called Type to Learn. Now, I am testing software in agile test teams for a Fortune 500 company. The insight I got while reading this book is that even when I was writing Type to Learn by myself, I was really working in a triad where collaboration was key. Now, the roles are different, but really it is the same problem with the same solution, which is to write acceptance tests that originally do not pass and then write code to make them pass. There is always a triad.
One thing I like about this book is that it works as a whole, so it is not information that you can just search for on the internet. It solves a non-trivial problem. It does not just deal with the happy path but also with what happens when things go wrong.
I am finding more and more in my career that I am given something like "The answer is 42. Now, implement it. Performance test it, prove it, and demonstrate your solution." (This is acceptance test-driven development!) This book has helped me to organize that type of approach. It is valuable for anyone architecting testing solutions for software. I like the idea of testing, designing, and documenting the solution and letting this drive the code development. It is an economical way to write software, and it provides a framework to measure software quality.
Review By: Jennifer Flamm
12/29/2011
Ken Pugh's "Lean-Agile Acceptance Test-Driven Development" walks the reader through the creation of an acceptance-testing framework by covering the test strategy, evolution of user stories, scenarios, development tests, and issues with test implementation based on evolving business requirements. Throughout the book, Pugh uses a CD rental store to illustrate a better process that a triad of the customer, developer, and tester can use to develop a system. Using this process, the team can avoid a situation where testing occurs at the end of an iteration and the tester finds a disconnect between the test data and the software implementation. I definitely recommend this book for anyone involved in development or testing who wants to deliver quality software.
Pugh guides the reader through the development lifecycle from the requirements definition to the creation and modification of the acceptance tests. Regardless of where you are in the software lifecycle process, you can apply the principles that Pugh discusses. Parts one and two of the book use the CD rental store example to discuss the concepts behind creating a simple testing strategy, development of an initial acceptance test, creation of a user story, scenario development, and scenario tests for a complicated system. Pugh embraces good programming practices, such as decoupling the user interface from the business logic and the importance of software testability at all stages. Even in the example world, it is refreshing that Pugh recognizes that some use cases are best handled outside of software.
I found parts three and four most helpful, as they consider issues from a business perspective such as: a value proposition, test presentation and evaluation, a ubiquitous language, and other uses for tests. These sections also have case studies of larger, more complicated, real-world scenarios that build upon the principles from the earlier chapters. If you are trying to convince your coworkers about the benefits of ATDD and are encountering resistance, chapter 25 mentions some reasons for resistance and reiterates the importance of delivering a testable system that is of higher quality.
Pugh emphasizes the benefits of constant communication and instant feedback between the triad. Each time "Tom the Tester" has a question about a test, the other members of the triad provide a timely response, which results in positive synergy for the whole team. While Pugh gives the characters roles, he always reminds you that regardless of your title as a developer or a tester, you can play multiple roles in the triad.
Each five- to ten-page chapter is easy to read in a short time period and concludes with a bulleted summary that highlights the key points, making them easy to remember and apply. Overall, this is an excellent book packed with information and takeaways for anyone interested in delivering high-quality, testable software.