Agile Acceptance Testing

Gojko Adzic has been doing some good writing on acceptance testing in agile development. See his article here: http://gojko.net/2008/09/17/fitting-agile-acceptance-testing-into-the-development-process/
I'm not sure whether Gojko considers acceptance testing as a part of what he calls 'normal agile development' or not, but to me, it's an integral part of development. I see coding and testing as two parts of a whole. I wrote a long posting in response to his post, and so as not to waste it, I'm going to include it here too.

Here's an example of the business-facing testing activities we do during the iteration. I wish I could do a nice graphic like Gojko.

Day before start of iteration - product owner goes over stories with us, we ask questions, get some examples, perhaps break a big story into thin slices, go away and think about it. Examples and overview may be put on wiki, along with any pictures/flow diagrams drawn. Product owner posts "conditions of satisfaction" for each story on wiki.

Day 1 of iteration - Retrospective, then iteration planning, we write and estimate task cards for all coding and testing activities for each story, until we have enough stories to keep us busy for at least the first few days of the iteration. Testing cards for each story might be "Define high level tests", "Write FitNesse test cases", "Manual exploratory testing", "Write GUI smoke test", "Obtain test data". Then demo last iteration to customers. Then release last iteration's code.

Day 2-3 of iteration - Write high level test cases, which involves more discussions with customers, perhaps design meetings. Do paper/whiteboard prototyping with customers where needed.

Day 2+ - When a programmer picks up first task card for a story - start writing detailed test cases, in FitNesse if that's possible for the story. When a happy path FitNesse test passes, write more interesting test cases, collaborating closely with programmer (sometimes it's the programmer writing the FitNesse tests)
When a testable chunk is available for exploratory testing, start on that. Show things to customers and get feedback whenever possible.
When all coding task cards are done, do exploratory end to end tests, automate GUI smoke tests where appropriate. (Or if we're working in thin slices, do this for each slice).

We focus on completing one story at a time, in priority order. Not everyone can work on one story, but the idea is we are trying to get stories done. Bring in more work as we have room. If we took on too much, figure out what to set aside, and focus on finishing.

So not all our integration and exploratory testing is done the last couple of days, it's spread out more. On the last day, we are wrapping up the last story or two.

If we have a big theme coming up, we write cards to have brainstorming, research and design discussions for an iteration or two in advance of actually starting on the stories.

For my team, we've found that getting into too much detail in advance wastes time and leads to confusion. We do try to get examples, but we try to keep the discussion pretty high level and not get too much into details.

Much Ado About Agile! Agile Vancouver 2008

I am fortunate enough to have been invited to present at Agile Vancouver (www.agilevancouver.ca). They're calling their conference "Much Ado About Agile", and Ken Schwaber is giving a keynote. Here are just a few of the presenters: Jim Shore, David Anderson, Janet Gregory, Frank Maurer, David Hussman, James Grenning, Jennitta Andrea. It's scheduled for Nov. 4 - 6, and registration will open in the next few days.

I'm doing a track session called "Are Agile Testers Different?" and a tutorial on an iteration in the life of an agile tester. I'll only get to do the tutorial if enough people sign up, so if you're interested, please sign up early!

The best part of any conference is the informal connections you make, talking to people facing the same issues you face, getting lots of ideas and inspiration. This conference will be a wonderful opportunity for that kind of networking. And it's put on by a fabulous group of volunteers, who are going out of their way to give back to our agile community. Please consider it!
(And a note to U.S. residents - flying to Seattle and renting a car to drive to Vancouver is WAY less expensive than flying straight to Vancouver, plus, I think you still don't need a passport at the border if you drive, but I could be wrong about that).

Agile Book Writing

Janet and I turned in our "final" manuscript (still have copy editing, proofreading etc to go) last night. The book is available for preorder on Amazon. on Amazon - how do they know how many pages it will be???

One cool thing (at least, in our opinion) is that we used agile practices to write the book. A year ago, we got together and mind mapped the whole book. Janet came up with a release plan, and we started in on it. We had two-week iterations. At the start of each iteration, we mind mapped two chapters, then started writing. We used an ftp site to keep the latest version of each chapter, and to pass chapters back and forth. (This was important, because otherwise it would've been easy to lose track of the latest version, or 'walk on' each others' changes). We each had a folder - 'Awaiting Janet Review', 'Awaiting Lisa Review'.

At the end of each iteration, we 'released' two chapters - that is, we posted them on our book site for review by our volunteer reviewers. We used a spreadsheet on Google Docs to help our 'source code control', checking chapters in and out. We also kept a 'to do' list and notes for the bibliography on Google Docs.

We got continual feedback throughout this development cycle. We were able to visually share ideas with our mind maps (using MindJet MindManager software). We kept in constant touch with IM, and met a couple of times in person. We build a couple extra weeks into the schedule during the holidays, and kept working at a sustainable pace (it's really hard to write a book when you have a full time job!)

By March, we had all the draft chapters posted and informally reviewed. Janet put together a new release schedule to revise all the chapters in time to send our draft manuscript to the publisher June 1. We did a major refactoring of the book, moving sections around and completely reorganizing the automation section. We made our deadline, although I confess we were more 'agile' about our release plan, we worked on the chapters in a different order than planned.

We waited a few weeks for our official reviewers to give us their feedback, then we did the last, most punishing stretch, making our final revisions. We again did a fairly major refactoring, eliminating two chapters and folding the information in them into different chapters where it made more sense.

If we took even more time, we're sure we could make the book even better. In fact, we've gotten some ideas here at the end that we could have used. However, people have been clamoring for this book (which is gratifying) since we started writing it. Every time we go to present at a conference or help a team, people want to know when it will be out, and complain when we say "January 2009". We feel (and so does our publisher) that it's better to get some really useful information out earlier, rather than to keep polishing the book and get a more perfect book out later. I don't know about you, but that's how my agile development team works, too.

It's been really interesting to see how we were able to apply agile values, principles and practices to writing a book, as well as to developing software. Wonder what else could be done better with agile!