The Origin of TweakLR

Note: This blog post was originally published on Loadtester.com as an article. We have re-published here as an effort to retain useful information from that web site after merging with Northway Solutions Group. Some material may be slightly modified to retain relevance.

This week marks a milestone for me personally, as well as for Loadtester as a company. Two years ago, we had an idea to create a utility to be used to make our lives as LoadRunner consultants a little easier. There have been a few stand-alone utilities that have been in my “secret toolbox” for a while. Some of these were shared with me from others in the load testing field, and some we created within Loadtester. I decided we needed to have more than just another utility, but a MASTER utility. We needed something that could evolve over time and be given away to the general population to see where it could be taken.

As is usually the case, the conversation started over some barbeque at a local Nashville restaurant. This was April of 2008. I met up with my friend Boyd Patterson to talk about how to implement such an idea. Boyd is the best guy I know to bounce an idea like this off of. He is an excellent developer who chooses to stay in the area of testing. He could impress most developers with five lines of code. He is the head of Patterson Consulting, and the creator of Test Design Studio. Once Boyd became a little frustrated with the limitations of the development environment (IDE) for HP’s Quicktest Pro, so he just decided to build his own! And it rocks. Check it out if you haven’t. Boyd was quick to point out that my idea of building a more generic engine to “host” a set of functions as plug-in modules would be easy to create within Microsoft’s Windows Presentation Foundation (WPF) and C#. So I asked him for help on a prototype. A few days later, I had one to test out.

Boyd handed off the prototype to us, and created the utility so that we could simply create our own functionality and then hook into the main TweakLR interface. There are only three public properties or methods that you need to worry about when creating your own functions.  We immediately started coming up with ideas for functionality. We had about two dozen really good ideas that came out of the brainstorming session, but three that rose to the top that we felt like we could implement first. I enlisted Tim Chase and Anthony Lyski to work on the additional functionality. The result of their work are the three utilities that currently ship with the first release of the tool. When you first look at the application and see on three things you can do, it may not seem like much. There are a lot more features planned. We just didn’t want to hold up getting it into your hands while we were working additional features. Tim and Anthony had completed their main code sections by September of 2008. Testing began.

As we worked through the bugs, time got away from us. Keep in mind, all of us were doing this project on the side when not working our regular jobs (which are typically more than 40 hours per week). Sure, we could have just hired a developer, but then it would have no soul. And what’s the use of doing something if you can’t put your own passion into it – at least in the beginning. The next steps were getting a manual completed, registering the domains (tweaklr.com and tweaklr.net). We originally scheduled the first release around May of 2009.

It’s no secret 2009 was a very bad year for a lot of people, and the HP Partner community was no exception. TweakLR began to take a back seat because it was more important to stay in business and keep our customers happy than release a software utility. Time slips away and before I knew it, I was renewing the tweaklr.com domain (October 2009). This got me motivated to get the product out, so we sent our a beta release to a few good friends. From that feedback we made several changes to the product which required more testing. We can’t expect our clients to test everything they do, and then decide not to do that ourselves.

By the end of 2009, it was time to prepare the web site for TweakLR. I began working on the main pages and realized I needed a way to deliver the software through a registration process. We also needed to have a way that users of the product could interface with us and the other users as a community. Currently, this is through email support. After researching,  and learning more about Drupal, PHP, and MySQL than I care to talk about, we finally had an EASY way to register and download the product. The forms and process may seem very simple, but it was hard to make it that easy. It required more testing. What about application security of the forms? What about spammers on the forums? What about…. all that stuff?? Again, more conversations over barbeque were required to sort it all out.

We thought we were ready to roll March 2010, but we found another bug at the last minute, and this time it was something we needed a little help with. I again contacted my friend Boyd, who offered to help me out of a jam and get the product out. In the process of fixing the bug, he found a few other things that he thought could greatly improve the product and made those changes. This required more testing. Do you see a pattern here?

While TweakLR may not seem like all that big of a deal to some people, it was a big deal for us, and I hope you get the bigger picture. It’s not about the three simple functions that it performs in the first version. We have created something which you can tap into. Even though it is geared toward LoadRunner, it can be anything you want it to be.  Once you have the code completed and compiled as a DLL, just put the file in the “plugins” directory and open up TweakLR, and there it is. What we are hoping is that our fellow LoadRunner buddies will use this opportunity to create additional functionality and we can start sharing some really cool modular tools that can all be contained in a single, global utility. We have a lot of ideas, and we’d like to hear about your ideas too.

In addition to trying to make our life a bit easier, I am hoping that HP will take notice. This could be a good vehicle to advance some features of LoadRunner that might not be able to make it into a major build. If there is a call for functionality to a limited audience, why not just create a DLL that can be distributed and use TweakLR as a way to utilize it without having to build it into LoadRunner? What if there is an idea for a new feature in LoadRunner being considered inside research and development, and they would like to know how the market would react to it ? Create a DLL for it – even if it is time-limited for a beta group. It could create a more frequent dialog among the most frequent users of LoadRunner, and help create a better and more useful LoadRunner product from the feedback they give.

I would like to thank Boyd Patterson, Tim Chase, Anthony Lyski, and all of our beta testers for helping turn this idea into a reality. It would not have happened without you.  If you decide to use the product and like it, please let them know how much you appreciate their effort.

As of May 2012 – TweakLR is currently back in the lab for another revision and will be re-released at some future point. We will updated the blogs when this happens to keep you informed.