Agile testing :

These same imperatives can underlie a practice of Agile Testing. Agile Testing would most obviously apply to Agile development projects, but it should work - perhaps less well - on conventional projects too.

The first step is to abandon the notion that others communicate at us with requirements and design documents, and that we communicate back at them with test plans and bug reports. We've always realized that the documents we base our tests on are flawed - incomplete, incorrect, and ambiguous - but our reaction has been to insist, in our usually powerless way, that the document producers do better. But now we can see that "better" will never be good enough. Documents can't be an adequate representation of working code. So we can let free of the illusion that documents will save us. We can view them as they are: interesting texts, partly fictional, often useful.

Rather than communicating at people, we need to join and encourage the ongoing project conversation. Testers and developers should sit in the same bullpen, share offices, or occupy alternate cubicles. Many testers should be assigned to help particular developers, rather than to test pieces of the product. The test plan should evolve through a series of what James Bach calls "drop-in meetings" - short, low-preparation, informal discussions of particular topics. These will result in what James Tierney calls "test doclets" - short memos addressing a specific issue. Test status should be reported via big, public, simple-to-read charts that answer specific development questions like "what parts of the product can we stop worrying about?"

Conversation with the customer is as important as with the developers. Remember: the customer is trying to figure out what they need, want, and are getting, in large part by trying out the working code. Testers should sit down with them as they do that. Creating some tests together is an excellent way for both of you to learn what matters - and also to describe it to the developers in a clear and concrete way.

That's an instance of the Hands-On Imperative. Exploit that with developers as well. The normally strained relationship with them will be less so if they see you wanting to get started testing, even on something unfinished, especially if your expressed goal is to help them improve and complete it. They'll value tests they can run as they continue development.

Agile Testing is not the answer for all projects. Neither is any of the Agile Methods named in the first paragraph. No single approach can be. But now is a time when we need more experimentation with project styles, the more so because there's an increasing move toward standardization of software development practices, a move that in my opinion is entirely premature.