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
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
- 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
- About the authors
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!!!
It's awesome to see some new content from you. I've never done the 30 days of testability challenge before, but your recent posts have inspired me to check it out, and also share it with my team as well to see if they are interested to dig into some of these items as well. I'm also interested to hear what you think about the book you will be getting into. The best of luck to you on the challenge.
Post a Comment