(Yes, I know I should be writing about the DT/TD Summit.  Still sorting my brain out.  And preparing for an upcoming trip, working on my materials.  Thus my current puzzle…)

I’m seeking the sources for some quotes I’ve been using.  In each case, I’m reasonably certain I heard a speaker use the phrase in a talk at a conference.  Alas, I can’t remember the speaker.  Even if I could, the phrase may not have been original to that person.

Can you help me out?  Do you know who said any of these things?  If so, please drop me a note in the comments.  Please?  I use these phrases, and I’d like to be attributing them correctly.  It bugs me that I have to say “I don’t know who said this, it’s not original to me, but I think it’s really useful” each time I use these phrases.

“Testability = Visibility + Control”  I find this to be a useful definition that suggests ways to improve testability by creating more/better mechanisms for seeing what the software is doing and controlling its actions.

“If it hurts…do more of it.”  I like counter-intuitive advice that works.  In this case, I find this works because doing something painful over and over puts you in a better position to figure out why it hurts and how to make the pain go away.  Sometimes the answer is to automate the process, in which case having done it a lot helps.  And sometimes just doing the thing - whatever it is - over and over will help you identify the core essense and eliminate all the other extraneous stuff.

“Agile development delivers a continuous stream of value.”  I like this description of Agile because it provides a nice way to contrast the results of using Agile methods with Phased approaches and also with lip-service chaotic Agile that isn’t actually Agile at all.  Bottom Line: If the process does not result in the delivery of a continuous stream of shippable software that’s of value to the business, the process isn’t Agile.  Further, anyone with a business background can understand why a continuous stream of value has the high probability of providing a greater return on investment than an uncertain big payoff at some nebulous point in the future.

So…who said these things?  Please help me out…

Chris McMahon said, “…even if someone were to give Elisabeth her pony, other functional testers would still find a dire need for aardvarks and platypuses.”

Yup. I agree.

Throughout my FTT:TNG post, I kept referring to “a tool” that would do a ton of cool stuff. Actually, that’s not exactly what I want. My wording was imprecise. Sorry.

So let me restate what I want.

I want the capabilities, but I don’t want them all in a single tool. A single tool that did everything I said would probably be too unwieldy to use effectively, too cumbersome to deploy, and too constricting. It would take too long to create. And if it came with it’s own proprietary IDE designed for people who don’t code, plus a hamstrung scripting language that’s supposed to be “easy,” and a record-and-playback feature? Well then we’d be right back where we started with commercial tools, only with tail fins in addition to bells and whistles.

So I what I really want isn’t one thing, but a set of things that can be plugged together. (I did eventually say something like that, though it was easy to miss. 3800 words into my massive wish list, I wrote: “Perhaps each part could be a separate open source project and the complete solution would involve deploying the full collection, much like an XP team that uses Eclipse+JUnit+JWebUnit+Ant+etc.”)

In five years, I’d like to think that we’ll have a collection of utilities, tools, frameworks, libraries, etc. that make tests more graphical, connected, transparent, and integrated. Such a set of things would make it possible for teams to assemble their own ponies, aardvarks, and platypi to fit their particular context.

In somewhat related news…

As Chris mentioned in his post, we held the first DT/TD Summit yesterday. Great stuff, and many thanks to all who participated!

Once I wrap my head around what I learned, I’ll be blogging about it. (I facilitated the meeting, so I’ll need a little quiet time to reflect before I’ll be ready to share my insights…)

On the toolsmith-guild discussion forum, Russ DeWolfe asked me what problem I was trying to solve with all this next generation tools talk.

Russ brings up a good point. I talked a lot about what I want, but not about the core problem that I’d like to see solved. So here’s what I hope a next generation of functional tools could do.

JUnit revolutionized unit testing by creating an incredibly simple yet powerful model: setup/test/teardown. Further, it provided a bare bones framework for implementing and executing your tests. In the past, a developer wanting to automate unit testing would have to write some kind of harness, would have to think about results reporting, and would have to think through how to structure the tests. JUnit simplified all that and allowed the developer to focus on just writing one test at a time. The result: a developer can write a unit tests within minutes. Thus JUnit significantly lowered the barrier to automated unit tests.

Fully automated functional testing still has numerous barriers. And Agile teams that want to integrate automated acceptance testing with their continuous integration process need fully automated tests.

Watir is an excellent example of something that helps break through barriers…it’s possible to create a lot of tests very quickly with Watir.

But after a while it becomes difficult to manage those tests. And reporting is still a challenge. And the business people who must agree that the automated tests reflect their acceptance criteria have a hard time (sometimes) understanding what all that Ruby code is doing.

Various people have tried various structures including table driven things (like FIT/FITnesse) and Domain Specific Languages. But none of these approaches has quite succeeded in transforming the state of the practice the way JUnit did for unit testing.

So I’d like a thing, or more likely, a collection of things, that break down the barriers to effective, fully automated end-to-end tests in a lightweight way, like what JUnit accomplished. I’d like it to be general enough that it could be used anywhere. But like JUnit, I’d like to see that general applicability achieved through simplicity rather than through gold plating, tack-another-feature-on-the-beast.