Team Guide to Software Testability
This book is 85% complete
Last updated on 2019-08-08
About the Book
Team Guide to Software Testability is the third guidebook in the new collection from Skelton Thatcher Publications.
A practical guide to how testability can help bring teams together to observe, understand and control the systems they build. Enabling them to better meet customer needs, achieve a transparent level of quality and predictability of delivery.
The ‘Team Guide’ collection is designed to help teams building and running software systems to be as effective as possible.
Guides are curated by experienced practitioners and emphasise the need for collaboration and learning, with the team at the centre.
Manuel Pais is an independent DevOps and Delivery Consultant, focused on teams and flow.
With a diverse experience including development, build management, testing and QA, Manuel has helped large organizations in finance, legal, and manufacturing adopt test automation and continuous delivery, as well as understand DevOps from both technical and human perspectives.
Manuel is co-author of the Team Guide to Software Releasability book and lead editor for the remaining books in the Team Guide series.
- The Team Guide series
- 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
- Why we wrote this book
- Feedback and suggestions
1. Use a testability inception deck to visualise current state and identify improvements
- 1.1 Recognising the value of testability and overcoming challenges through cross functional collaboration
- 1.2 Identifying the needs and contributions of different roles to foster a testability mindset
- 1.3 Overcoming common challenges to setting a testability focus in the context of pressures on teams
- 1.4 Building an initial picture of your testability using the Team Test for Testability
- 1.5 Creating a testability inception deck to foster a sense of purpose as a team
- 1.6 Identifying a shared model of architectural pain for the systems that the team is responsible for
- 1.7 Looking beyond the team to judge the impact of stakeholders and adjacent systems on testability
- 1.8 Setting a pragmatic focus to start the testability journey among all the product priorities
- 1.9 Summary
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 historical data to remedy architectural design problems which inhibit feedback
- 3.1 Explicitly design your architecture for testability
- 3.2 Principles of implementing high testability architectures
- 3.3 Understanding the role of testable architecture in increasing team collaboration
- 3.4 Identify architectural improvements to iteratively increase testability
- 3.5 Case Study - Transitioning from hard to test to high observability, control and shared understanding
- 3.6 Summary
4. Adopt ephemeral development environments to diversify testing and shorten feedback loops
- 4.1 Common challenges with creating, using and maintaining test environments
- 4.2 Leveraging your development environment for fast feedback
- 4.3 Enhancing your development environment for balanced testing
- 4.4 Summary
- 5. Utilise events and metrics to model risks in production for continuous improvement of your test strategy
6. Use team testing reviews to reduce testing debt and enable sustainable delivery
- 6.1 Consequences of testing debt on team well being and sustainable delivery
- 6.2 Adopting a whole team approach to risk mitigation and minimise testing debt
- 6.3 Exercise: Evaluating the Team Testing Experience using the 10 Ps of Testability
- 6.4 Use team incident learning reviews to improve detection, recovery and prevention
- 6.5 Create a physical board to visualise and prioritise testing debt
- 6.6 Summary
- About the authors
Appendix 1 - 10 P’s of Testability Notes
- Production Issues
This book is published on Leanpub by Skelton Thatcher Publications
Developing and running modern software systems requires teams of motivated and well-trained people; however, most IT books are written for the individual technologist. The Team Guide series from Skelton Thatcher Publications takes a team-first approach to software systems with the aim of empowering whole teams to build and operate software systems more effectively.
The Leanpub 45-day 100% Happiness Guarantee
Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
Free Updates. Free App. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers), EPUB (for phones and tablets), MOBI (for Kindle) and in the free Leanpub App (for Mac, Windows, iOS and Android). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.