Much like every site on the internet, we use cookies to help analyze traffic and improve our website. As outlined in our privacy policy, any information is only used internally and is not shared with outside organizations.
Learn More

Today marks the end of Mercury/HP WinRunner support in Test Design Studio, and the end of era for our products.  Our Test Design Studio product of today exists only because of the early days using WinRunner.  So how did we get here?

I began my career in test automation when WinRunner 6.0 had just been released.  To show how far we have come, that was the first version of WinRunner to support syntax highlighting of keywords!  WinRunner was a powerful automation tool, but used a proprietary language called Test Script Language (TSL).  While based on ANSI C, it was still unique in the market.  Being specific to WinRunner also meant you would not find much, if any, third-party support for the language.

In those early days, functions were king!  Libraries of functions were amassed in “compiled modules”, and you had to create special startup scripts just to load all of those libraries to make them available for your tests.  Keeping up with those libraries was the inspiration for one of our first software tools… Function Browser!

We published this utility as a download on the Mercury support website, and it quickly became one of the highest rated tools you could download (along with our stand-alone GUI Map Editor utility).  You could browse all of your compiled modules and Function Browser would parse out what was available and even provide a code viewer.  There was only one problem… you still had to edit your files in WinRunner.

We decided to create a more robust version of our utility that would allow full editing, and Function Manager was born.

Not only could files be edited, you had great control over your editing environment and tool windows abounded with detailed information for all of your libraries.  You could even enter specially-formatted comment headers for your functions that could be parsed to expose more information about your declarations.  Function Manager provided a great extension to our original utility, and was the first commercially available product we offered.

Not long after the release of Function Manager, a new product began to emerge… QuickTest Professional.  The early release of the software was missing many of the features that made WinRunner such a great tool, and it was largely ignored by existing WinRunner users that didn’t have a specific need for the new object-based approach.  Those of us who waited were rewarded because the early release of QuickTest Pro was not pleasant.  I first began seriously using the product with QuickTest v6.5, and even then was immediately disappointed at the limited editing environment offered by the early IDE.

Around this time, the .NET Framework was still in the early stages, but had great potential over Visual Basic 6 that was used for our current products.  With no upgrade path from VB6 to .NET, I had already started duplicating our Function Manager product using .NET.  With the knowledge that the QuickTest IDE was severely lacking, I decided to apply our Function Manager process to QuickTest Professional and the VBScript libraries.

This early product was called Script Manager, and was only used internally as I experimented with functionality.  It did not take long to have syntax highlighting and full IntelliSense for the new VBScript-based files.  The tool even managed to provide a feature only recently added to the QuickTest Professional product itself… editing multiple scripts at once!

While working on Function Manager and Script Manager in .NET, the newer releases of Microsoft Visual Studio at the time were really beginning to shine and expand on an already great editing experience.  Switching between the Visual Studio IDE and the QuickTest Professional IDE was jarring.  I could tell a significant drop in coding productivity when using QTP compared to Visual Studio, and this lead to constant frustration.  This was not something I could tolerate, and something had to be done.

This is when Function Manager and Script Manager merged into Test Design Studio… an IDE that bridged the great functionality and productivity of Visual Studio with the runtime capabilities of both WinRunner and QuickTest Professional.  Many users were still using both automation platforms at the time, and Test Design Studio was a single IDE that provided support for both applications.  What started as a simple way to parse TSL function declarations for WinRunner eventually grew into the feature-rich client we have today in Test Design Studio.  While I always hoped the tool would be well-received by the community, I was never prepared for the run-away success it has become!

As we prepare Test Design Studio for the next phase of it’s life, we just finished removing the final lines of code that supported WinRunner.  Much of that code was some of the first .NET code written for Function Manager.  The old language parsing framework is not compatible with the new direction of the tool, and it’s time to let go of the past.  Anyone I talk to who experienced the early WinRunner days feels like something is missing in our current environment.  It was a great time, and we had a great community.  I look back fondly on the experience I personally had building test automation with WinRunner and the journey it started for me and this company.