I was at Agile Fusion last week, an event intended to explore the ways testers could be integrated into XP, and though there was a lot of good dialogue, there was no resolution. I am not disappointed by this, as this issue is not something you simply "solve" in one week. But it has left me thinking as I believe skilled testers can greatly improve the agile development process.

During a tutorial I attended today about the Lean Development Toolkit, I found inspiration. Mary Poppendieck talked about concurrent engineering in the automotive industry and commented that software development could benefit by adopting the technique. In concurrent engineering, the product is developed with multiple, parallel activities aimed at developing different components of the finished product.

So, I have the following idea, though it is really half baked. Consider the beginning of an XP project (or any XP iteration for that matter). During the planning game, testers contribute by asking questions that help expose areas of risk and necessary consideration. Though the whole team should be doing this, skilled testers are particularly adept at this. (Lisa Crispin raised this idea during Agile Fusion.)

The rest of the planning game proceeds as normal. Once stories are established and tasks laid out, development begins with normal pairs of developers, with an occasional third member (a tester) who can move among pairs, sort of like a bee collecting pollen and cross pollinating. The tester, at this point is observing more than participating, but she is gathering information about the internals of the software, the habits and biases of the programmer, the architecture decisions, etc.

The tester only does this gathering for s short period of time, at which point the tester (or testers, though I have though about this much) break away from the development activities to focus on their activities. From what I understand of context driven testing, such testers will formulate theories about how to test specific systems, effectively developing strategies and plans for testing the system (though not huge documents of test plans and specifications, but rather ideas and strategies).

At the end of the iteration, the tester will discuss with the entire team his theories about how to test the system, the important risks and any concerns they have. This information is a vital part of the iterations retrospective and this feedback should be used for the next planning game. The developers hand off a working system to the testers and begin their work in the next iteration. The testers have a working system to test; both for their approaches of how to test the system and the system itself. They revise their plans, expose new risks and identify defects (or areas for improvement). The testers should still join some pairs to constantly learn about the system internals and the developers should integrate the contribution of the testers in their automated tests. This workflow continues for each iteration.

I would characterize this workflow as a weaving in and out of the tester with the pair programming activities. It allows the testers to collect information that helps them better formulate their test strategies, but gives both testers and developers the freedom to concentrate on the tasks that they are best suited to.

Brian Marick (and other in the context driven school), commented that one of the core principles of context driven testing is that testers would rather have working software to test than documents about how they would test the software. He also noted that context driven testing develops testing strategies appropriate to the system they are testing. I think that the workflow I outlined satisfies both these desires; testers get working software in each iteration that guides the refining of their strategies. The developers also get feedback, with each iteration, about what issues they need to think about and hopefully use this information to improve their automated tests and overall code.

There is another element that appeals to me in this idea. I think developers prefer to build something first, then reflect on it, and integrate their reflections into the software, proceeding in a very incremental and iterative fashion; developers are anxious to dive right in. Testers (from what I have observed), prefer to think about the system, consider it from many perspectives and generally develop a hypothesis before they actually start. I think both perspectives are appropriate for their task. A developer's job is to produce software, so active development directly supports the production of working software. A tester's job is to inspect software, rather than produce it. The tester wants to formulate a strategy first to avoid random "hacking" testing that is undisciplined and immature. There is conflict if you try to force the developer to spend too much energy and time before they get to write code and not allow the tester enough time and thought about how they would test a system.

So, I think the approach I am outlining allows both developer and testers to work together without getting in each other's way. The "weaving effect" is just enough collaboration to provide a benefit without trying to force one to emulate the other's job.

Another benefit is that it provides an iterative and flexible environment for testing. The testers are integral members of the process, and with each iteration they have a more functioning system that they can test and revise their approaches with. I would hope this increases quality and the efficiency of the software and team.

At this point I am starting to babble and it is getting late. I have lots more ideas in my head, such as pair debugging (something I have done with testers), but I want to get feedback. I have already discussed some of these ideas with others. There seems to be enough merit to continue the discussion, though I don't know how much.