Mercury Interactive Musings

I recently redid my office and in the process rediscovered some cool Mercury Interactive swag I had accumulated over the years.

For some reason, I really do miss Mercury.  HP is fine, but they’re so big and focused on so many areas that it doesn’t have the same feel that Mercury – a company dedicated to just test tools – had.  I was a true Mercury acolyte.  I attended numerous Mercury conferences, was an active member on their forums and was an evangelist for all their products.

I contributed so much to the Mercury website that I was christened a Mercury maven – one of a handful of people who really had the ear of the company.  Here are some images of my Mercury  swag – the crown jewel being an authentic Captain Mercury “action figure.”

Top 10 Signs You’re an old-time Mercury WinRunner Automation Engineer

10. You cause compile errors in QTP by ending your statements with semicolons

9. You separate all your function names with underscores,  like set_window and button_ok

8. You keep forgetting not to use () in your wait statements

7. You still have your certified WinRunner product specialist card

6. The first thing you did when you installed QTP was set it to default to the expert view

5. You know what TSL is

4. You think TSL is better than VBScript

3.  You call QuickTest Professional Object Repository a “GUI MAP”

2. You think E_OK is a cool return code

1. Back in your day, they didn't have a fancy, keyword-driven graphical “user-friendly” interface – they had a big, white,  empty window that looked like notepad – and you not only liked it, you LOVED it.

The Death of Winrunner

I came across some old HP test tool training manuals recently and they reminded me of that cold, fateful day in February of 2008 when I received the HP end-of-support email officially killing off WinRunner. The following is my automation tribute to its passing.

What WinRunner taught me

The main thing I learned from the death of WinRunner was not to fall in love with any tool, but to focus instead on learning fundamentals (key concepts that can be used for any test automation tool). I've touched upon this a little in my Selenium Sucks – QTP Rules post, but there's still more I want to say.

Regression Tests – What can and cannot be automated

I began my software testing career using Winrunner. It helped me to learn the basics of automation that I still apply to any test tool I use today. First and foremost, it taught me which regression tests should and should not be automated. Based on my old training I found out that test cases like:

• Usability tests
  
• one-time tests
  
• ad hoc tests
  
• tests without predictable results
  

are “red flags” tests — ones that should not be automated. You wouldn't believe how many times over the years I've had the same conversation with managers about why 100% test automation is unrealistic. I always use the test types that I mentioned above as examples of tests that cannot, or should not, be automated.

Record and Playback Automation Testing

Win Runner also taught me the dangers of automation snake-oil like record and playback, and painful lessons on why it never works. Now, when people ask me about Selenium IDE –Selenium's “Record and Playback tool” shivers still runs up and down my spine, and not in a good way. Simply put: DON'T use it.

Learn the Fundamentals of Programming with WinRunner

Because I refused to use the record and playback functionality, I was forced to learn Winrunner's TSL (C like) language. This was a gateway for me in learning how to program and how to debug code — skills that have turned out to be some of the most valuable technical skills I've ever learned.

Winrunner Central Repository

An example of one of the many transferable skills I learned is to make tests as readable and easy-to-maintain as possible. One way to accomplish this is to have a central location where your tests can store their automation test object data. In WinRunner this is called a GUI map.

The official definition of a GUI Map is “a text file containing the names and descriptions of all web objects learned for proper recording and playback of scripts.”

This is a big help because if a field property changes –a field name, for instance – you only need to make the update in one place. So, if you have 1,000 tests all pointing to the central location, you make the change once, not 1,000 times. This saves a huge amount of time and makes the whole testing framework more maintainable.

This central location concept can also be found in QTP and Selenium: a WR GUI Map equals à QTP's Object Repository which equals à Selenium PageObjects.

Performance Testing

Also — this may sound strange since WinRunner is a functional testing tool, but it taught me about performance testing. Back in the day, I worked for an insurance company that used a mix of technologies, from old-school mainframe to these “newfangled” internet web applications.

In order to put a proper load on some of our systems, I had to leverage Winrunner as a GUI VUSER inside LoadRunner to be able to create a realistic performance testing scenario. This opened a whole new world to me, as I learned performance testing concepts like:

• The difference between load testing and stress testing
  
• How to run realistic performance tests
  
• How to read performance testing counters
  

This is also a poor man's way of trying to get a “real” user's perspective of screen refresh rates when placing a load on a website using http web Vusers. With the release of LoadRunner 12 and the ability to run Selenium scripts as GUI Vusers from the controller, I'm actually able to dust off and use this old trick.

Selenium vs WinRunner

These valuable lessons are still paying off for me years later; especially during the past several years as I gradually transitioned from HP's test toolset to open-source tools like Selenium.

It's also a good lesson for the people who ask me which test tool or Selenium language binding they should use to learn automation. Pick one and go with it, and focus on really learning the automation concepts and fundamentals that can be applied to any tool.

There's an old saying I've modified for automation engineers: “If you can't be with the test tool you love, love the tool you're with!”