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
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
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.
An example of one of the many transferrable 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.
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.
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 tool set 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!”