I’d like to thank one of our senior developers for inspiring this post. Dave Vines recently sent out an excellent, thought provoking email on how we should be moving towards a tester driven development model. I’ve slightly reworded his email:
“One thought that I’ve recently had was that perhaps we need “Tester Driven Development” rather than “Test Driven Development”. Let me try to explain.

We are currently very much a “Developer Driven Development” organization:
We gather new requirements and (typically) farm them out to the development community to investigate
Once a work item is identified, it is typically a developer that

• Writes the Design document
• Calls the meeting to develop the use cases
• Identifies the interesting scenarios
• Gathers the development resource to write the code
• Decides which iteration in which the code will be written
• Hopes that test will have the resource to test all the use cases and “interesting edge cases” that have been identified and for which code has been written (or not written)

In effect the developer owns the work item

In a “Tester Driven Development” organisation I would see us:
Gathering new requirements and (typically) farm them out to the test community to investigate
Once a work item is identified, it is typically a tester that:

• Writes the design document
• Calls the meeting to develop the use cases
• Identifies the interesting scenarios
• Gathers the test resource to test those scenarios and use cases
• Decides which iteration in which the code will be tested
• Indicates to development what use cases and code will be needed and when

In effect the tester owns the work item

This would be a massive culture shift for a department, but one that makes it clear that the desired deliverable is actually requirements that have been tested, not requirements that have been coded and may have been tested if test had enough resource. “

(more…)