This topic is designed to provoke curiosity.

Like it or not, performance testing is a micro-scale development effort. All of the aspects of a typical development model are present, requirements management, estimation of level of effort, development, QA (of a QA script) and deployment. Where we have some level if distinctiveness is in our deployment model and potentially some circular effort where an environment changes prior to retest and we are back into the development phase to fix previously working test artifacts.

Nestled right there at the core is ‘development. ‘ It’s a nasty word to tool vendors who want to sell the sexiness of a tool that any business analyst can use effectively. Yet despite this piece right in the middle the level of actual development skills entering the profession is dropping as manual testers and business analysts are thrown into a performance testing effort. What’s the result? Well, we can all recall people wanting to set capture buffers for correlation beyond the length of a 32 bit address space, no conservation of virtual user resources and deployment in a model that is certain to drag down the performance of the virtual users, with extensive logging as an example.

And yet, these poor development skilled individuals are expected to find errors generated by more robust developers of the application set. “Houston, we have a problem.” How can someone who is not following best practices for scalability and performance in their own development efforts effectively measure and find issues with those who are supposed to be building high performing and scalable code? If I don’t know what a snipe looks like how can I find one when sent on a snipe hunt?

But there is an easy solution. If you don’t know the language of your testing tool today, learn it. There are tons of books designed for easy instruction in computer languages. Volumes with titles such as “…for Dummies, “ “Idiot’s Guide…” and “Head’s First…” litter my own bookshelf for reference and education.

Think about how you make use of resources in your virtual users and during your tests. You have finite constraints on RAM, CPU, DISK and Network. How, as a developer, are you making use of these resources? Are you treating them like the precious elements that they are or are you acting like you are at Mardi Gras with an unlimited supply of beaded necklaces to toss from the floats? How you make use of these resources directly impacts how many users you can get on a host, how efficient they are in operation and how subject to influence they are when the box itself becomes resource constrained. No longer will you have to tell developers “Do what I do, not what I say…” instead you can be very happy if a developer wants to look at your script as part of defending your results when you call their child (code) ugly.

There is not a single person here who cannot pick the language of your tool. There is no excuse. If both my 62 year old Uncle who is a railroad engineer with a hard science degree in Zoology and my 40 year old brother with a degree in finance can pick up a usable amount of C in a couple of months anyone can do it.

Start with your next set of scripts. Think like a developer on how you treat your resources. Implement appropriately. Study your language if you are not proficient in it. Act like a developer, think like a developer and then one day you will wake up and it will become a natural part of who you are.

You can always take a cue from actor Cary Grant. He was not always the urbane gentleman of stage and screen as we know him today. He grew up in extreme poverty and adopted the role of a gentleman as an escape from the poverty around him. Be a developer: Fake it till you make it!