Jim Shore posted a nice Introduction to Agile for QA People on his blog.   I thought it was great as far as it went, but it didn’t explicitly mention some of the things that I have found to be extremely important, at least, in the corporate IT environment.  I tried to leave a comment there, but I was too long-winded for his comment system.  (If you’ve not read his post, please do so now.  I’ll wait.)  Here’s the full text of my comment:

Jim, I think you’ve left out, or under-emphasized, an aspect here.  It’s perhaps not explicitly called out in the XP literature, and isn’t mentioned by Scrum (neither of which mention the QA department as an entity), but it’s an important aspect in successful Agile adoptions in corporate IT environments, in my experience.  That aspect is Defect Prevention.

If the QA people take the normal approach of waiting to the end and then looking for bugs, they’re going to be outside of the tight feedback loops of Agile development.  It’s so much more effective, and more Agile, for QA to be intimately involved throughout the process.

You mention helping the business provide clear examples of what they want.  A good QA person can help the business elaborate those examples to cover situations that might not have been considered.  It’s generally good to do at least some of this example elaboration with both the business and the developers.  Having these three perspectives at the same time is hugely helpful in covering the ground thoroughly and uncovering the odd cases that will show up later as defects.

You mention writing automated non-functional tests.  I’d also add automated functional tests from the business point of view of the full system.  These are often not included in the tests produced by the developers.  Fundamentally, these are executable elaborations of the business examples mentioned above.  Fortunately, there are tools that allow this expression in language that the business people can read to verify, “Yes, that’s what I mean.”  For many testers, connecting this business-accessible language to the system under development will require the assistance of developers.  This is an example of the partnership between various members of the team working to prevent defects, as the resulting regression test is an important tool to protect against losing or changing old functionality when new is added.

You mention doing exploratory testing, but I would elaborate that to include doing exploratory testing of unfinished features. Long before you can “find bugs,” you can notice spots where the developer’s understanding of the business’ desires are incomplete or slightly off-kilter.  Or, you can notice situations that were not foreseen when drawing up the business examples. Or, you can notice things that seemed reasonable when discussing them, but seem less so when seeing them on the screen. These should be brought to the attention of the business experts providing the wants of the business.

I know all of this is second nature to you, but it’s not to many of your readers.  The role of QA people in Agile development is much richer, more varied, and important than might be obvious from your description.  At least in corporate IT environments, I’ve found that this deeper involvement is important for success even when (or perhaps especially when) the development is following Scrum without the XP technical practices.