I recently got a copy of newly published book Agile Testing Condensed: A Brief Introduction by Janet Gregory and Lisa Crispin. I ordered a real-life physical version of the book, because for some subjects I like a real book in my hand. I got my copy on Amazon for $19.99. It's also available on LeanPub.
I own a couple other books by Janet and Lisa that cover agile testing. These other books have a lot more examples, details, and pages. This new book is a bit more current and "condensed" so I wanted to check it out.
I want to point out up front that this is not a thick reference book. Weighing in at in at 102 pages, this book is an overview. You'll find more detail in links and references mentioned throughout the book, and also in the authors' other books. In my opinion, condensed is good.
The book is broken into 12 chapters and these chapters can be read in any order. I actually find the last chapter "Ingredients for Success" to be a good place to start.
A bit about me. I am a test lead and usually my primary responsibility is helping to define test strategy for projects, as well as working on automation framework and test automation tasks. Naturally I focus on the areas of the book that impact me the most.
These takeaways are just a few high points that resonated with me. Some of this is more my interpretation of what I've read and may not be a complete representation of the authors' intent.
"Agile Testing" is kind of a weird term for me, but Chapter 1 makes the meaning pretty clear. Characteristics of Agile Testing include:
- collaborative, from inception to delivery
- supports frequent delivery
- focuses on fast feedback
- supports a whole-team approach to quality
The whole-team approach is a recommended quality mindset on an agile team. This means the whole team is responsible for quality. OK sure, but what does THAT mean?
In practice it means the entire team is responsible for completing the development and testing tasks. If a "dev team" is siloed and completing work that is then handed off to the "testing team", that is NOT a whole-team approach.
You might not be following a whole-team approach to quality if you're asking questions like this:
- How can I possibly test all of these newly "completed" stories in the last 4 hours of the sprint?
- OMG, are the devs already working on the next sprint??
- Development is done. When will QA be done?
- Why are there so many bugs?
Chapter 10 talks about how to visualize a test automation strategy by referencing a couple versions of the test pyramid.
In my opinion, the key guidance here is to push tests as low as possible in the pyramid. For example, if something can be tested with a unit test, test it there instead of with a UI test.
I would add that once we test something at a lower level, there is no value in testing it again at a higher level. For example, if we test a business rule with an API test, there is no value in also testing it as part of a UI test. In fact, there is a cost to this duplicate testing.
When strategizing how to test a particular feature, we need to think about what automated testing we are going to do at each level of the pyramid. Of course, that means that folks that do this automation need to communicate, which means that devs and testers may have to resort to talking. Otherwise, we are going to have duplicate testing or missing tests, and we want neither of those things.
This was briefly mentioned in Chapter 1 as part of the Testing Manifesto, and really resonated with me. As a member of an agile team that typically focuses on testing and test automation, I personally need to remember to focus on preventing bugs over finding bugs.
I've only scratched the surface of a few areas covered by the book. If you want to learn more, get a copy of the book. Ultimately you can consider this book as a pocket-sized guide to testing on an agile team. I plan to throw it in my backpack so that if I ever leave the house again, it will always be with me!
Janet and Lisa are huge in the agile testing community, and from what I can tell, they have spent most of their careers focused on testing, specifically related to agile projects. They are both very active on social media so if you want to learn more I suggest you follow them.