Yesterday Brian Marick made an blog entry with some thoughts considering alternatives to business-facing TDD. Here is an abstract:
Abstract: The value of programmer TDD is well established. It’s natural to extrapolate that practice to business-facing tests, hoping to obtain similar value. We’ve been banging away at that for years, and the results disappoint me. Perhaps it would be better to invest heavily in unprecedented amounts of built-in support for manual exploratory testing. An Alternative To Business-Facing TDD
It took me the whole night to realise, that I was faced with something similar. Personally I would like to call his idea Exploratory-testing driven development and I must admit that I was already confronted with this. Personally I would like to add some more context. In our organisation we have a huge product developed consisting of several software sub-systems written in C, C++ and Java. The Java sub-systems are build upon an JBoss application server and the key sub-systems, which is responsible for maintaining all the data from business point of view, is hard to test in the exploratory way, since it is hard to have the proper data in the system, you will need for more advanced tests. It’s possible, but hard, though.
During our last project-end overtime-schedule – yes, we’re doing waterfall… – I got the chance to get some more details on one C/C++ based sub-system, which is at the low-level end of the whole chain. All communication in the sub-system consists of xml-data. A collegue and I had a problem, so we contacted the main champion of that sub-system. We gave him the last snipplet of communication,
which came from the Java component. He took that xml-data, snipped a little here and there, putting a small xml-portion into a new root-container and – ta-da – he had all the data he needed to reproduce the behaviour in the sub-system he just had started.
This was the point where I realised what I called “exploratory testing driven development”. Within this particular sub-system it is easy to introduce a complete complex data-set with absolute ease (compared to the handbreaking things you have to do with the Java sub-systems).
An outline for me is, that I encourage support from development. Unfortunately though I think, that it is can be impossible to have complete exploratory testing support within an application and meeting performance and/or usability goals. Basically this depends mainly on the context of your application under test. But I will leave these thoughts like they are for the moment.