Agile Testing
I’ve know about this whole ‘Agile thing’ since around the signing of the manifesto and I’ll openly admit I was pretty anti-Agile as it seemed to just legitimize cowboy coding and push testers out of the picture. The community has generally softened their stance on dedicated testers and so has mine towards Big-A Agile; though I am much more of a proponent of little-a agile. Part of my transition into an agile tester was to join the agile-testing mailing list. Two of the frequent posters on there, Lisa Crispin and Janet Gregory have recently put their collective wisdom together and produced a nice book on agile testing called, appropriately enough, Agile Testing – A Practical Guide for Testers and Agile Teams (Amazon).
My first impression was that it is a lot bigger than I had expected coming in at over 500 pages. That’s a lot of content.
Its heft is divided into 6 sections:
- Introduction
- Organizational Challenges
- The Agile Testing Quadrants
- Automation
- An Iteration in the Life of a Tester
- Summary
Before going too deep into the review, I’m pretty sure I’m not the target audience of this book as I’ve been doing agile-ish testing for a number of years now, so I’m going to try and juggle the new and familiar personas.
The first two sections were actually the ones I found the most useful and have the most markup in them. In it they describe how testing and testers fit into an Agile team as well as the mandatory primer of what makes up an Agile team. The Cultural Challenges (chapter 3) and Transitioning Typical Processes (chapter 5) are tackle very real challenges traditional teams and testers need to tackle to have any chance at succeeding with a switch to Agile.
The Agile Testing Quadrants are a series of chapters which describe four types of tests Lisa and Janet have identified.
- Test-Driven Development
- Business Facing Tests
- Customer Facing Tests
- Technology Facing Tests
Of the four quadrants, I found the Business Facing Tests the most informative with its discussion on tools and techniques for determining what the software is supposed to do and how it is to do it. These techniques quickly can turn into test data. It was also nice that see that I either currently use or have used them all. Exploratory Testing and other UAT-ish activities fit into Customer Facing Tests with Michael Bolton contributing a nice piece on it.
This is a good time to say I really liked how they used outside ‘experts’ to flush out their sections. It’s nice to see people not afraid to tap resources when they don’t have enough the expertise to convey what they want. They also pepper the chapters with Lisa’s Story or Janet’s Story which lends credibility to things as they clearly practice what they are preaching.
The last 3 sections I actually breezed through and is why I mentioned before that I likely wasn’t the exact audience of the book. My copy has only a couple things noted in the Automation section and I’ve developed my own way of handling an iteration so that section was more of a compare / contrast what I’ve figured out over the last couple years.
If I could come up with a complaint about the book it would be its apparent focus on the XP variant of Agile which seems to be the least likely version to be picked up by transitioning organizations. It is pretty easy to overlook that though and pull out the juicy bits.
I’ve more-or-less drank the agile Kool-Aid and think this is the way testing needs to evolve in order to be successful. If you have been around Agile for awhile, this might not be the book for you, instead, you might be better off getting a book dedicated to a specific topic of interest (like Business Facing Tests or TDD or Continuous Integration). However, if you are new to testing in general, or to Agile testing specifically then Agile Testing deserves a spot on your bookshelf as it discusses all the key points in just enough detail to morph you into an Agile tester.