Upon recent refelections of Agile Fusion and the corresponding forum discussions, I've had a couple of "aha" moments.

We have been asking the question, "What is the role of testers in XP?". Perhaps this is the wrong question. It is a little too general and implies its answer is prescriptive and would be a proclamation.

A better question might be "how can a tester contribute to an XP project?". A slight difference in wording has significant difference in implication. It is open ended; it is not prescriptive but exploratory. It is the type of thing Lisa Crispin addresses in her book.

Still, I think there is more to this. One element of XP that is appealing is its simplicity. Furthermore, I am amazed as to how many contexts can be "reduced" (one of the "aha" moments, see this post) so that XP is appropriate. But, XP doesn't address all areas of software development; XP is developer and code centric.

Metaphor, Simple Design, Automated Testing, Refactoring, Pair Programming, Collective Ownership, Continuous Integration and Coding Standards are directly about coding. The remaining practices (Planning Game, Small Releases, Onsite Customer and 40-hour Week) are about either staying out of the programmers way so they can code or improving communication about what they are going to code.

Anything that is outside the realm of "coding" is not really addressed by XP and I don't think we should try to change XP to address these other things. I think it would hurt more than help; it would complicate XP and is beyond XP's intention.

But, there are other agile practices that address these other concerns and work in harmony with XP. Scrum is the best example. Scrum is about project management, not coding. When I am asked about the role of project managers in XP, I suggest scrum. Scrum is another process that collaborates with XP; it doesn't really change or extend XP. I think this is a key reason developers don't have allergic reactions to scrum. It doesn't get in our way and we can pretty much ignore it.

But scrum is great for the customer and project manager; it helps deal with many of their concerns. So, I think we should consider what would be an agile process for testing, or rather figure out what is "agile testing".

I cringe a bit even as I type "agile testing", as there has been some disagreement already over its definition. Perhaps a different name will be better, but I am specifically looking for a process, framework or practice that adheres to the following guidlines:

• is consistent with the agile manifesto
• will complement, not impair, XP

I think there is enough experience among people like Brian Marick, Brett Pettichord, Lisa Crispin, James Bach, Andy Tinkham, Cem Kaner, Elisabeth Hendrickson, and others (sorry if I left anyone out), that if you were to mine your experience, you probably could come up with some ideas and patterns that would address the above. I think a lot of Brian's posts to his blog, are exploring this.

Part of the confusion for me has been the scope of testing. One dimension of testing is directly related to coding, and these facets can benefit from tester/programmer pairing. But so much of testing is not about coding, but exploring risk, for example. These "para-coding" activities and goals are outside the scope of XP, but could complement XP and therefore make for a more productive team and a successful project.