Agile Testing with Lisa Crispin

I made a difficult decision to move on from my incredibly wonderful agile team at ePlan Services to take on new challenges at the equally wonderfully agile Ultimate Software. This leaves the team at ePlan with four programmers and one tester (plus two system administrators, a DBA and a ScrumMaster).

Even with two testers, the programmers pick up some of the testing tasks – ours is a testing-intensive financial application. The programmers often document stories on the Wiki, write FitNesse tests as well as automating them, do manual testing, and investigate functional test failures in the builds. Everyone on the team is willing to wear multiple hats. The sys admins sometimes do development and testing tasks, the ScrumMaster sometimes helps with manual testing.

Conversely, we testers help with production support, occasionally take on a simple development task such as changing text in a report, fix SQL query bugs if the solution is obvious to us,and the like. It’s one of the things I enjoy most about working on an agile team. Nobody’s stuck in a pigeonhole, and everyone focuses on common goals.

In the past, when we’ve been down a tester, the whole team pitched in to take up the slack. For example, when our Ruby/Watir expert left a few years ago, every team member bought the Pickaxe book, and helped maintain the Watir scripts and even write new ones.

So, I was surprised the other day when I heard a plan to have one of the programmers, who started out here as a tester, revert to the tester role until a new tester could be hired. Yes, he’s a terrific tester, and indeed has continued to do some testing tasks along with coding work. But why should he have to abandon his new role, especially as he’s really getting traction with his new skills, to do testing activities full-time? It makes no sense. Naturally, with his experience in the tester role, he’ll be an important resource, but his job shouldn’t suddenly revert.

I reminded everyone of how we normally handle this situation. It was a bit of a “doh” moment as everyone realized the whole team approach to picking up the slack has worked so well in the past, and there’s no reason not to keep using it. Everyone can pitch in on testing tasks, just like always. Every role on our team is equally valued, so nobody feels that testing is somehow “beneath” them. Everyone is committed to delivering the best software possible. The team velocity will drop while they’re short a member, but quality won’t suffer.

The Whole Team approach to testing has been so effective on my teams, and I expect it will work well on my new team too!

If you’re wondering whether our book is for you, read this comprehensive review by Brad Appleton in the Agile Journal. Janet and I are so excited that so many readers understand what we have tried to do with the book. We wanted to give pragmatic, practical help for agile testers and teams, and that’s what people say they are finding. Yay!

If you have read our book, please review on Amazon or your blog, and help other potential readers decide if it’s the right book to help with their issues.

The Agile 2009 program is ready, and it’s chock full of practical content. I know training and travel budgets have been cut, but this program is worth the investment. Of course, the best thing about any conference is the informal networking and learning from other participants. This year’s presenters include not only a lot of “big names”, but lots of in-the-trenches practitioners dealing with the same issues as your team.

I’m particularly excited about our testing stage program. Our track is in a large room, so we have included sessions that are highly interactive, and useful for a wide variety of participants. We have a great range of topics and session types. There are also lots of sessions in the Developer Jam and Tools for Agility stages that will be highly interesting for anyone involved in testing.

I just reviewed a book proposal that raised my ire. The skills and techniques that would be taught in the book were fine. The emphasis on context-driven testing was great. But the book appeared to be framed in a setting where testing is all about dealing with crises, trying to figure what testing you can squeeze in to a very short timeframe, making the testers somehow in charge of quality.

Testing skills are important, of course, and we testers add value with our special experience and viewpoint. But we can’t have much impact on quality by ourselves.

On the plus side, I’m seeing more and more teams around the world figure out that the best way to deliver a high-quality product is to move testing to the front, make testing and coding part of one process, have the whole development team take responsibility for quality, and work incrementally, iteratively and at a sustainable pace.

On the minus side, I see things like this book proposal that ignore the evidence of how this new whole-team approach is working, and that keep pushing a way of working that is 20+ years old and hasn’t resulted in consistent, high-quality software.

I don’t care if you’re using a traditional waterfall process, or agile, or something else. There is a pragmatic, practical approach to software development and testing that works. It’s more than specific testing skills and tricks. Discipline, communication and collaboration are the key skills and characteristics we need. Continuous integration and automated build processes that run good regression tests are as just as essential as automated source code control.

Testers do need to learn new skills and techniques. More importantly, they need to get up from their workstations and (physically or virtually) go talk to other development and customer team members. We need to find out how we can all help each other do our best work and delight our customers.

What do you think is the most important thing testers need to do or know? What book is missing that would send newbie testers in the right direction?