The “More Agile Testing” book is the sequel to the book Agile Testing written by Janet Gregory and Lisa Crispin. This book continues to explore the topic of software testing in an Agile context. It provides more than 500 pages of Agile knowledge to the software testing community, building on the Agile Testing foundations described in their first book.
The book covers many topics like the software testing skills, planning testing in an Agile context or testing the delivery of business values at the end of Scrum sprints. My favorite part of the book is the “testing in context” part that explores the particularities of testing embedded software, mobile apps or data warehouses. One of the very good ideas of the book is to ask Agile software testing experts to contribute to the book. Readers are able to learn the perspective of people like Gojko Adzic or Ellen Gottesdiener on specific topics. Another little gem of the book is the “Provocation Starters” appendix that lists questions about your product and that you can use to elicit examples or uncover assumptions. More Agile Testing has a good structure, each chapter having a clear description of what will be discussed and a summary at the end. It is well-written and easy to read, mixing explanations of concepts with examples that allow putting them in perspective.
I recommend this book to every software tester, even if they are not active in an Agile project, but also to every Agile developer, Scrum Masters and Product Owners that need to have a better vision of the collaboration and cross-functional aspects of Agile software development.
Reference: “More Agile Testing: Learning Journeys for the Whole Team”, Janet Gregory, Lisa Crispin, Addison-Wesley, 544 pages, IBSN 978-032196705
Quotes
If you can “fail fast” enough so that the failure isn’t too costly, you can learn from those mistakes to improve. You can also use fast feedback loops to refine your trials to change something that worked “OK” into something that works great. If your organization’s culture is such that mistakes aren’t tolerated, innovation is unlikely. Doing the same process, even if it’s not working, feels safe, so there is no reason to change.
The distinction between checking and exploring is interesting, but we’re not sure that testing definition goes far enough. Testing is more than “just” testing software. It is about testing ideas, helping business experts identify the most valuable features to develop next, finding a common understanding for each feature, preventing defects, and testing for business value.
The whole-team approach to testing and quality is possibly most critical when it comes to automating tests. Automated tests are code. Not only do they protect us against regression failures, but they help us to document our production code, telling us exactly what our system does. As we’ve mentioned before, they deserve the same care and feeding as our production code. When testers own test automation, they must spend large portions of time writing test scripts for stories in the current iteration, investigating test failures, and maintaining the existing automated tests so they continue to work as the production code is updated. There’s often little time left for crucial activities such as exploratory testing. Programmers who aren’t automating functional tests have no incentive to create testable code because they don’t feel the pain of code that’s not automation friendly.
While we don’t believe there are any “best practices,” we do believe there are core testing practices that benefit most agile teams. These practices give teams confidence to deliver quality products that delight their customers. With that confidence comes the courage to try new things and continually improve.