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.