Since Brian Marick pointed me in that direction, I started the investigation of Exploratory Testing driven development. It came to my mind, that I did not mean Exploratory Testing driven development, since Exploratory Testing is not driving the development. The more and more I thought about this the thing Brian pointed out seems to be Exploratory test infection rather than my first term. The term Exploratory Testing driven development is misleading, since the primary focus of the development should not be to have it properly set up for Exploratory Testing. Rather the value it delivers to the customer’s business is relevant. This might include easy information gathering during Exploratory Test sessions, but personally I think especially when performance is an issue the ability to do easy Exploratory Testing might conflict with intended business value.

Test infection describes the fact, that source code can be changed based on regression tests to assure no unintended changes in the behaviour as well as examples for the new changes – when considering test driven development. Therefore if you have a product which can be accessed easily within a Exploratory Test session for all the needed parameters a human tester might want to get to know, it should be called Exploratory test infected. Note that this definition goes beyond simply putting “everything” into some logfile. The human interaction within Exploratory Testing can go into directions which were not thought of during the development of the software.

The more I think over this I believe that there might not be a software which is fully Exploratory Testing infected. Due to this the engineer in me cries out for some measurement of the degree a software might be Exploratory Testing infected. During the next days I will think on possibilities for some measurement techniques for Exploratory Testing infection. Maybe I can then evaluate some popular software for this.