I think this book is a little overhyped. Don't get me wrong. The book offers many interesting insights and experience reports about how testing can be organized by an agile team. However, in my opinion, much of them are "common sense" or were already explored in other sources (as some reviewers stated: "more about agile than agile testing"). For example, suggestions like "begin with the happy path", "put test stories on your backlog to make the test activities visible", "when working with legacy systems, create tests for the new features and, then, treat the old code in small steps" and "i (the tester) used to put candies on my table to attract programmers" are all interesting. But, at least for me, that wasn't *ONLY* what I was expecting for. Also, is that really new to someone that has experience with test or software? Another example of my expectations was about the beginning with test automation chapter. I really liked to be alerted to evaluate the ROI of what needs to be automated, but where are the details of inserting these activities in a team? What are the steps?
As a practical guide I was really expecting to see *DETAILED* examples of software testing in an agile context, distilled in steps or recommendations for its application in other contexts. I wouldn't be bothered if these examples weren't directly applicable to my context, but at least I would know how decisions were made and how they worked out. Overall, I was expecting much more technical content and even without all this the book managed to have 576 pages. Ok, again, maybe it was just my wrong expectations, but be advised to what you will get. If you are new to Agile you can read this book. Also, even if you are experienced, but want to refresh some good "common sense" practices it's a good read too. Otherwise, don't create many expectations as I did.Get more detail about Agile Testing: A Practical Guide for Testers and Agile Teams.
No comments:
Post a Comment