Customer Reviews

Agile Testing: A Practical Guide for Testers and Agile Teams

5 star:		(18)
4 star:		(1)
3 star:		(3)
2 star:		(3)
1 star:		(0)

 

 

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.

"Agile Testing" is an excellent and must-needed book related to testing in agile product development. Much has been written about test-driven development on unit level, however, little has been written on higher level testing and the role of testers and test departments in Agile development. This book changes that!

The book consists of 6 parts. The first part if an introduction, the last part is a summary. The introduction starts with a short explanation of agile testing and then followed by the ten principles of an Agile Tester. One of the key messages in this book is "the whole team approach", meaning that testing should be within the team and should not just be "the testers job". Anyone in the team can test, however, teams will probably still benefit from having a test specialist of a test expert. This mindset is one of the key thoughts the book repeats over and over again. In the last chapter, the authors summarize their thoughts with the seven key success factors for testing. Again, "the whole team approach" is #1. The agile testing mindset -- the proactive, creative cooperative mindset as opposed to a quality policy mindset -- is the second success factor.

The second part of the book describes organizational challenges. In my opinion, this part was perhaps the most needed. In many organizations testers struggle to find their role on agile product development. The chapter relate to cultural change, team logistics and transitioning typical processes. I thought the chapters were enlightening. Parts I liked were the discussion about the change in role for QA managers and especially the experience that, without proper coaching, a lot of traditional testing people might simply flee your agile development effort.

The third part of the book takes Brian Maricks four testing quadrants and explains these in details. These quadrants describe the different types of testing and how they would happen in agile development. The unit testing part is not covered thoroughly, as the authors (correctly) mention that this is covered well by other literature. The higher-level functional (acceptance) testing is covered well, including advise on automation. Exploratory testing is also covered in detail and explains its role in agile development clearly. Non-functional testing is covered reasonably well, especially considering that this depends so much on the type of product you are developing.

The fourth part of the book focuses more on test automation. I didn't find much new information in here, though it was a good summary of modern test automation and some of the challenges and difference between traditional test automation.

Part five follows an agile tester though an agile project and explains for every step in an agile project what the role of an agile tester is. It starts with the role in release planning and estimating. Then it explains the preparation before an iteration (product backlog refinement) and how early example tests can (should) be written. It continues with iteration planning and then the actual activities an agile tester would do during the iteration. This part also includes the important discussion related to the use of bug tracking systems. The part ends with the iteration review/retrospective and some final works about the actual delivery.

As mentioned, in my opinion, a good book on agile testing was absolutely needed. And the authors do not disappoint at all. Their knowledge about the subject is obvious. They have put much effort in sharing actual experiences by the many sidebox experience sharing stories. They touch the seldom touched parts related to organizations and roles and transitioning. Their writing is clear, though sometimes repeats itself (but not so that it is annoying). Not much topics are left unanswered, the book is thorough.

All in all, this book is exactly the kind of book that was needed. I'd recommend it to anyone interested in agile development and especially testers who have a hard time finding their new roles. Great work! Five stars.

I'm a QA Manager in a department of 30 testers, most of whom have spent their entire careers on traditional SDLC "waterfall" projects. One of my, perhaps unenviable, tasks is to help transition these folks onto newly formed Agile teams. While I've had success, I wish I had this book sooner!

Crispin and Gregory have created a practical and very readable reference that shines a light on the roles of testers, and testing management -- areas that are often neglected in most of the work that I've found. Perhaps most importantly, they address the fear and apprehension that testers feel when faced with the prospect of joining an Agile team -- the same emotions I've seen (and felt) time and time again.

There's an appropriate mix of high level concepts and low level specifics. The book starts with discussions of principles and mindsets and moves on, in the later chapters to discuss such things as specific techniques of test automation. All along there are anecdotes from interviews with real agile teams and quoted articles from testing luminaries such as Brian Marick, Michael Bolten, et. al.

I've already begun to incorporate much of the material in these books into my own writings and presentations and it's certainly gratifying to see some of my own ideas mirrored. I now have solid references to back them up! I highly recommend this book for testers and testing managers who are planning to start on Agile projects, or who have years of experience on them. There's surely something in this book that will influence you.

I have never been a tester, but I have written some system test patterns so I have spent time learning from
the best testers in a medium-sized organization. Here's the summary of the principles Lisa and Janet think
are important for an agile tester: Provide continuous feedback; Deliver value to the customer; Enable face-to-face
communication; Have courage; Keep it simple; Practice continuous improvement; Respond to change; Self-organize;
Focus on people; and (I love this) Enjoy!

Now what's startling to me is that as I look back on all those testers I interviewed in our pattern mining
exercises (over a decade ago) -- I realize that those testers had all these qualities. Good testers are good testers are good testers. Agile just makes us more aware of what they do. That's certainly worth celebrating and enjoying!

Lisa and Janet clearly know the agile patterns for testing, so I'm giving them two thumbs up!

The main theme of this book is fitting testing tasks into agile projects, and as such this book really is long overdue. Most agile books are written by programmers for programmers, leaving testers in particular to fend for themselves. No wonder why so many of them feel lost in this world. This book definitely delivers on the promise to ease the transition for testers and QA engineers who suddenly found themselves on an agile project. It has a testing focus and presents things in a way that testers, coming from more traditional process oriented software projects, should understand. The key pillars of practice on which the content of this book stands are improved communication, the whole team approach, agile testing quadrants and automation, so the book efficiently points traditional testers to new knowledge and ideas that they need to focus on to contribute to an agile project. It also provides a solid framework for executing traditional testing tasks in an agile environment without lagging behind the development and causing the project to fall into the "mini-waterfall" trap.

I would also recommend it to project managers and team leaders as they will be able to see the project from the testers' eyes and complement their knowledge about quality on agile projects. As such, it is especially an important reading for teams that consider JUnit the extent of their "testing" process. The book raises valid concerns about commonly overlooked tasks such as test planning, security, performance and usability testing, documentation testing and provides some very practical advice how to plan and execute exploratory testing efficiently.

"Agile Testing" is a great reference and a wonderful read. Unlike so many technical books it is easy to follow and the examples by Crispin, Gregory and contributors brought back memories of similar experiences and challenges in my own career.

Early in the book is the statement: "Agile Testing doesn't mean testing on an agile project". This statement is critical; the practices, techniques and ideas in this book can help anyone working in an Agile environment, or any environment, grow in his or her career.

Personally I loved the emphasis on automation and customer interaction, the chapters summarizing the testing quadrant and the key success factors are my favorites! Additionally the authors were kind enough to include a glossary, which are so necessary in a good reference book!

Some authors are good at presenting theories but unable to connect them to practice. Other are good at telling stories from the trenches, but without being able to produce an analysis of the situation and propose some solutions. On the less examined domain of agile testing, Lisa Crispin and Janet Gregory are, luckily for us, presenting a book that covers both the personal experience of being a tester in agile projects and a conceptual vision of the place of quality assurance in software projects. Thus you will find in this book "stories" that comes from past projects and "mind maps" that helps to have a high-level vision of the material of each chapter.

The book offers resource to organize the quality assurance and testing activities in an agile project. It explains also the relationship between test automation and agility. It provides also a part dedicated to the chronicle of the agile testing activities during project life, showing how every member of the team could contribute to quality.

I think however that the more interesting contribution of the book is Testing Quadrants. This concept classifies testing activities depending on their focus (technology or business) and their intent (supporting the team or validating the product). Adding an agile perspective to the original work of Brian Marick, the authors provide resources and examples for each quadrant to make sure that you will cover all the aspects of testing for your project.

This book is certainly a very valuable resource for every people involved in software testing, even if this is not in an agile project. It will also be valuable for ScrumMasters and project managers that have to think on how to integrate the testing activities in their projects.

I understand how hard it is to nail down Agile testing and a good understanding of Agile is essential to become part of a team as a tester. Besides describing Agile, the book offers little in the way of actual information on testing on an Agile project. The emphasis in the title is Guide for Agile Teams - the Agile Testing isn't really discussed other than a tester is on an Agile team and you need to know what this means.

Agile testing is a great book to both new and seasoned test engineers and test managers. At 533 pages, the book might feel a bit heavy but it is actually a pretty light and practical read if you read it to get a solid foundation on agile testing and then as reference. Note that the book is not about test coding techniques.

Part I is an introduction to agile testing and proposes ten principles for agile testers. What I don't know is if there are really 10 principles or if Crispin and Gregory forced it to be that specific number because it sounds better than 9 or 11. In any case, this chapter is a must read for all. Part II discusses organizational challenges, specifically cultural, logistical, and transitional from typical processes. This is a must-read for managers and team leads, and highly advisable for engineers if you want to have a successful test organization fully integrated with an agile organization. I personally encourage the division between development and testing to disappear completely. Part III is about he testing quadrants proposed by Brian Marick (one of the Agile Manifesto signatories) a while back. This is the first time I see the quadrants treated in larger detail and highly recommend it as a must for all.

Part IV is about test automation. It is a good read to understand the advantages of test automation and proposes a test automation strategy. This is a good starting point for test organizations that are new to automation but for mature test automation organizations it might add little value. Test code writing techniques are beyond the scope of this book. Part V illustrates the previous parts and then some by following a tester's activities through an agile iteration and the activities prior to it.

One problem I see way too often in test organizations and the way companies treat their test organizations is due to a lack of understanding not only of the difference between Quality Assurance and testing but also because of the place testing has hi people's minds. This book is a big help to create a cultural shift for the better.

How delightful that two of the agile community's "rock stars" of testing have teamed up to write the guide that every agile team member needs on agile testing!

Chock-full of side stories, examples, wisdom points, and handy chapter mind maps, the authors cover the entire range of possible topics you need to know about agile testing. This book will serve your team well and is an excellent book to include as part of your team's community of practice book club.

In addition, I urge all business analysts moving to agile to get this book. Business analysts need to extend their skills and knowledge into the testing arena. With guidance from Lisa and Janet, you'll see how the testing mind set truly drives development to deliver value.