I’ve often found that Developers and Testers misunderstand each other, even when they have a congenial relationship. (And in some shops, the relationship is anything but congenial.) Developers often don’t see the value of the Testers, or get annoyed that the Testers find issues that weren’t mentioned in the requirements. Testers often think Developers only consider the nominal cases, and don’t give enough attention to the edge conditions. Often, neither understands the others point of view. Michael Bolton, on the agile-testing list, said,

I had an epiphany the other day: TDD is exploratory testing that drives product development. As a programmer, you have a goal, but how you reach it is mostly up to you (and to your (mostly programmer) colleagues). In the course of writing a failing test, you learn a little; in running it, you learn a little; in making it pass you learn a little more; and the results of those three learnings greatly determines your decisions about the next test–and bit of code–that you write and execute on the way to the goal. You’ve followed that process, and written about it; I think that is at least to some degree exploratory learning.

I realized later that Elisabeth Hendrickson has been making the exact same point for some time, but backwards–she has a great story in which she was trying to explain to an agile developer about exploratory testing. The result of the last test greatly informs your decisions about the next test, she said, to which he replied “Ah! It’s test-driven testing.” I don’t know why it’s taken so long for me to conclude that if that’s true, there’s a parallel in describing TDD as exploratory development.

Michael writes from the perspective of a Tester. Translating this to my perspective as a Developer (and a test-infected one, at that), I would say

• In Test-Driven Development, each test informs and drives the creation of the next bit of system functionality.
• In Exploratory Testing, each test informs and drives the creation of the next test.

Personally, I find the mind-set of Developer and Tester to be subtly, but incredibly different. It’s impossible for me to think in both ways at the same time. It’s difficult for me to switch between these modes of thinking. And I think, from empirical evidence, that I’m better at this than most developers. So an insight like this one of Michael’s is a true gem, that helps me to better see the whole picture.