Sponsoring a "New" Book? #30DaysOfTesting Testability

Observations for when you start looking at various book titles related to niche topics in software testing. First is that they can be hard to find. Second, they can be mighty pricy. What is the cost when it comes to learning? True, but there are a variety of factors one has to consider, such as, "OK, I really don't have close to $100 to drop for a specialty book at this exact moment."

Having said that, occasionally one finds interesting things in interesting places and sometimes those things are in the process of percolating. It is in this guide that I have chosen to make my mark for "Day Three" of this challenge... yes, I'm writing about it on "Day Seven", let's not quibble here.


Begin reading a book related to testability and share your learnings by Day 30.

To this end, I've decided to help fund a book in the process of being written (or at least to be written for Leanpub distribution). Said book?

Team Guide to Software Testability

by Ash Winter and Rob Meaney

Learn practical insights on how testability can help bring team members together to observe, understand and control customer needs, ensuring fitness and predictability of deliveries.

Now I will have to say up front that I will probably not be able to provide a 100% complete read of this book because the book is literally being written as I've purchased it. However, I will be more than happy to review what has been written and post my findings and actions of it by the end of March. Who knows, perhaps more of the book will be delivered by that time and I'll be able to offer some more details when that happens.

This is what the book says it will ultimately include:

Table of Contents

• Foreword
• Introduction
• Why is testability important
• What does hard to test feel like
• What does testable feel like
• What leads to testability being neglected
• What is covered in this book
• How to use this book
• Feedback and suggestions
• 1. Use a testability inception deck to visualize current team and system state and create an environment for improvement
• 2. Adopt testability mapping to expose common smells of hard to test architectures
• 2.1 Gathering data on poor architectural testability to detect systemic problems
• 2.2 Low testability architectures contribute to slow feedback and deficient decision making
• 2.3 Identify the symptoms of poor architectural testability
• 2.4 Exercise: Measure the impact of testing smells on your architectural testability
• 2.5 Understand how testable architecture can impact your team’s testing efforts
• 2.6 Summary
• 3. Use risk and incident data to remedy architectural design problems which inhibit feedback from testing
• 4. Adopt ephemeral development environments to diversify testing techniques early and create shorter feedback loops
• 5. Utilize events and metrics to model risks in production for continuous improvement of your test strategy
• 6. Adopt incident postmortems to maintain a testability focus as part of your team’s continuous improvement strategy
• Terminology
• References
• About the authors
• Notes

It seems like a good place to start and I for one like to know I'm helping to fund progress on books I'd like to see be written. Win-Win!!!