Agile Testing: A Practical Guide for Testers and Agile Teams

I finished reading Agile Testing, on the recommendation of Mary Poppendick. It’s a thick book, and it took me longer to read than I originally thought it would.

I found it too long, to be honest. It covers both testing and agile principles. For me a better fit would have been if it only focused on testing, implying that I am not the target audience. For the Agile part I would recommend other books on the subject.

The testing parts, however, worked as a muse for my thoughts. It wasn’t long before I was thinking of how I could apply the different aspects mentioned in the book. For instance the book suggests that if the test suite start taking too long to run, it could be split into a quicker suite run each check-in (or my preference each compile) and a longer suite that runs in a build. I realized that most teams I know of would have a hard time splitting their test suites up into quick feedback suites run each time the code compiles and a longer list which run each night. This ties back to some of the problems with TDD where early practitioners risk just producing test after test without considering their value.

Another idea I had while reading the book was that it could be quite easy to produce a test suite for a REST-api using curl and a set of script-files. This suite could easily be automated as well, without need of much programming experience. Then again, it’s not difficult programming either.

The book suggests thinking of different types of tests as features are implemented. Which is good to have as a sort of checklist, and I agree that features should be considered from as many angles as possible for risks or if they can be implemented simpler. However I do not see this as a tester activity or a “programmer” activity. I see it as an obligation for everyone in the team. I do greatly agree with “the power of Three”.

I believe that the book could have been shorter and more concise. Also I could argue that the book isn’t a practical guide, but rather an introduction to agile testing. With this I mean that you shouldn’t expect concrete examples of how to set-up an automated regression test suite. It will however greatly describe the benefits of one and suggest that not every test is suitable for automation (I can see how it’s easy to get carried away with automation).

Despite the fact that I didn’t enjoy the book as much as I had hoped for I would still recommend reading it. However I would recommend readers whom want to focus on the Agile processes to read other books on Agile instead of the chapters discussing processes.