5 Reasons as why HTTP Debugging tools should not be used for preparing Load Testing Scripts.

20 Jan

In Recent times I have seen a kind of trend where in performance testers use tools like fiddler/yslow/httpwatch for scripting purpose in spite of having fully licensed version of the LoadRunner or other performance tools.I find this approach to be somewhat immature and prone to many errors if done by someone who do not understand performance engineering concepts or someone who does not understand the semantics of the web communication. I also find this kind of trend bit disturbing and harmful to the load testing industry for many reasons. I will list down some of the reasons why I feel this is a very bad idea and why one should not take this way for scripting purpose for preparing their load testing scripts.

I have encountered many times in my career where in the application in spite of working with supported protocol do not get recorded by the load testing tool. On further analysis of the issue, I did come across certain findings that either the setting which we use for recording the applications were incorrect or we were recording in the unsupported environment or it was just that firewall or DEP or some antivirus software setting were blocking the recording. So for sake of this post I am not writing here anything on as how I troubleshoot recording problems but will surely take some time later on to write on this as well. It’s interesting topic and deserves a separate post. So let me go back to original purpose of this post and write some of my thoughts why one should not use fiddler or any other HTTP Debugging tool to script a load testing script,

1. Tools like Fiddler/Yslow are the http debugging tools and not the scripting tools. They show http requests as resources are downloaded and interpreted by the browsers. Since page contains many resources, it becomes hard to tag these resources to the main request unless you are page author. Since the requests captured by these tools are context less and are not orderly distributed so I feel it cannot be used for scripting purpose and so they cannot replace the load testing tools.

2. Building the post requests from these tools is somewhat harder compare to get requests though not completely impossible depending upon the type and complexities of applications.

3. Since requests are displayed context less or in uneven order, correlation or capturing dynamic values is somewhat hard and prone to lot of errors resulting in many hours being wasted.

4. These types of tools follow the web standards and to know and understand information generated by these tools in real sense one needs to know and understand various RFC’s involved in the web communication. I have seen most of the Performance testers are unaware of these standards.At least this is my observation. It has taken years for me to understand as how web communicates.

5. From project finance prospective, we should not forget that we are paying five to six figure amounts to the licensed load testing tool vendors for using their product, so it makes more sense to ask them to fix these recording issues rather than using HTTP Debugging tools for scripting purpose. Also it looks bit odd when we use Open source HTTP Debugging tools to script when we have licensed version of the load testing tool. If you have program management office or PMO, who are auditing your projects, then they are surely going to scream on you for wasting so much of amount on load testing tools and not using it to their full potentials or capabilities.

Finally I would like to mention here is that this post is more about using right tools for the right job. HTTP Debugging tools are for debugging the web http communication, so I suggest let’s use these tools for debugging and load testing tools for preparing load testing scripts. In case for any reasons, if you are unable to record the script in spite of having supported protocol, then by all means you have all the rights to shout at the vendor and get the issue resolved.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: