The Whole Team Approach

I appreciated David Evans’ review of Gojko Adzic‘s new book, Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. David makes the point that agile quality is a whole-team responsibility, and that Gojko changed his original title from “Agile Acceptance Testing” so that anyone on an agile team, not just testers, would read it.

Janet and I push the Whole Team approach throughout our book as well. In fact, it’s #1 on our list of “key success factors” for agile testing. No team will succeed in the long run unless everyone on the team is committed to delivering the highest possible quality. We all know it’s impossible to “test quality in”. Tests form the foundation of our ability to delight our customers. But it’s so easy to misunderstand or miss requirements, even if you’re a disciplined team following all the agile principles and practices.

Here’s my latest concrete example of the whole team approach. My PC got upgraded to Vista 64 bit, and at the same time we upgraded to the latest Watir version (1.6.2). It took me a lot of time to get the Watir suites working again, not only due to the upgrades but because of technical debt. We had let a lot of little problems in the scripts slide, and failed to update them for all the changes in the app.

Who all was involved in this effort?

• The product owner agreed to a two-point story to get the scripts working again. (The story got put off for two sprints due to other emergencies, but that was partly my decision). So the business agreed to the importance of knocking out this technical debt, getting back the ability to run some important regression tests, and maintaining the scripts’ ability to speed up exploratory testing.
  
• A teammate who is a sys admin and programmer helped me with Vista settings (if my hard drive goes to sleep, the suite stops and waits) and differences in IE behavior (whether a new window is started or the old one used, having to confirm close window, etc)
• A teammate who is a tester and programmer paired with me some to fix bugs and problems, for example, regular expressions that didn’t work anymore because the html changed.
• When I learned from other Watir users that modal dialogs are old-school, and there are newer and better techniques, I discussed this with the other programmers who agreed. This might start an effort to evaluate whether we should change these in the interest of testability.

This example doesn’t speak so much to Gojko’s communication solutions, since it doesn’t deal with coding new functionality, but it does show how the whole team gets involved in anything to do with testing, and with keeping our app testable.

If you don’t currently enjoy working with a team whose members are all committed to quality and testing, read both of our books to learn why you need this whole team commitment, and some ways you might get it.