Freigeben über

the poetry of testing

  • Artikel

God Save the Queen! (A curious statement … from my American point of view. But given what history has recorded of certain of England’s Kings I’ll grant the gender bias. Anyway, Save Her all the same as she presides over a country of such glorious breweries!)

If you haven’t guessed it already, I’m visiting England. I’m also in a pub (you probably guessed that too). And I just met with a half dozen or so local testers who convinced me (with the offer of free pints) to meet for a book signing. I almost never turn down a signing and I never turn down free beer, especially at the current exchange rate.

Upon parting, they urged me to turn our conversation into a blog post. Here it is. I hope it doesn’t embarrass me in the morning.

A single signature seeker was a developer. When I asked him why he bought my book he answered that he wanted to make sure his testers weren’t successful with the “tricks” I preached in it. He intended to frustrate them by writing code that wouldn’t fail that way.

I smiled and told him that if this was a soccer, excuse me … football, game I would rip my shirt off and celebrate my goal. He looked at me funny. I think the testers got it. I bet you do too.

He went on to describe why developing code was better than testing it. He talked about the challenge of wrestling with the compiler and deftly parrying the attempts of the IDE and the operating system to thwart him on his mission. It was a battle to him, a conquest. He was a Knight, fighting for User and Binary.

It was a great story, and I didn’t get permission to identify him so I won’t but his passion was fantastic and the world is a better place because he’s in software development.

But if developers are the fighters, I think of myself and my fellow testers as the bards. Testing, to me, is poetry. As I test software I have visions of inputs mingling with data, some are stored internally; some are used temporarily and discarded. I hear music playing as inputs move through the app and find their way to a data structure or get used in some computation. It helps me to think about the inputs in this way, it helps me understand what the application is doing with the input I give it and that in turn helps me to think of ways to break it. Every potential sour note represents some possible way the developer may have screwed up. Imagine your app processing input. Listen to the poetry it recites, it will tell you when it’s going to fail.

I find this especially true of testing web apps. I envision in my mind the formation of SQL queries that my inputs cause the application to make. I form impressions in my mind of the HTML traffic that is transmitted from client to server and the response back again. What is the application doing? Where is the data going and with what purpose? These are deep, existential questions worthy of the bard in all testers. And they find bugs. The more I can picture the internal processes going on in the application, the better I am able to understand how the developer might have made a mistake.

The music of the pounce is what makes it all worthwhile. That moment in which it becomes obvious that the software can do nothing but fail. It’s euphoria, the equivalent to scoring a winning goal. But, please, keep your shirt on. That’s a caution-able offense in football and we don’t want developers to be brandishing yellow cards at us.

Comments