Mercury Interactive, WinRunner, and QuickTest Pro
Introduction
This document was created because of the major amount of confusion out there about Mercury's intentions with WinRunner and QuickTest Pro. There have been a lot of questions about whether scripts would have to be converted, thrown away, or be reusable. I talked with Mercury over the span of a couple conference calls to get things cleared up. The content and direction of the this document comes from questions that were offered by QAForums users and questions that I had for my own knowledge.
This thread should not be replied to, please reference it in other threads. Thanks. I will update this thread as needed, with information confirmed by Mercury.
From what I have gathered from questions that I've been asked and the statements that I'm hearing, I think *most* of everyone's fears about this new dynamic can be summed up with what Mercury has been saying all along:
WinRunner and its support are not going away.
Now, the 'how will things be handled in the future' and 'will WR do this and will QTP do that' issues are going to take some discussion. So, here we go.
"Ok, I got QTP and I've got an app that I'm testing with it. What about my WR stuff? Should I just throw those scripts out?" No, no, no. Again, I say, "No." QTP is going to (if not already) have the ability to launch WR and have your scripts run. You're not going to lose all the scripts, etc. that you've built. You've had your WR scripts call other WR scripts before... it's going to be the same concept. And what's coming in the "near future" is a centralized results set. Where you run your WR/QTP scripts and they call QTP/WR scripts and your reported results at the end of your test run are all in one place.
So an environment that has been using WR and need a .NET solution would build .NET app scripts in QTP and:
a. Have your WR scripts call your QTP/.Net tests
b. Run your QTP/.Net scripts and call your WR scripts as needed.
Mercury understands that with some 10,000 WR customers, there's an inordinate amount of architectures, frameworks, harnesses... there's no way to come up with one catch-all that will "convert" WR stuff to QTP stuff. So the idea is to reuse WR stuff via the QTP/WR Integration.
Let me reiterate this again, so there is no confusion:
[*]WINRUNNER AND WINRUNNER SUPPORT ARE NOT GETTING PHASED OUT.
[*]WinRunner will be able to call QuickTest Pro scripts.
[*]QuickTest Pro will be able to call WinRunner scripts.
[*]What one cannot do, the other will.
Licensing
To review, there are two ways to licenses a product: node-locked and floating. Node-locked refers to assigning the app to one machine; floating allows a license to be shared between machines at any given point in time (2 floating licenses allow the app to be accessible from an entire lab's worth of PC's but can only have 2 instances running at any given point in time).
Before I continue, I need to state that I cannot tell you exact pricing that MI has set up for the licenses, however, I *can* give you an idea of what costs more one way than the other.
That said, we've got:
| WR | Node-Locked |
| WR | Floating |
| QTP | Node-Locked |
| QTP | Floating |
| OFT | Node-Locked |
| OFT | Floating |
OFT? What's that? That is the new "Optane Functional Testing" license (NOTE: This is a working name for the license, it may change). It is WR and QTP with the integration. I'll get to that later....
If you're using WR and now need the ability to test in an environment not supported by WR, you have 3 options:
[*]Upgrade WR to QTP. You LOSE WinRunner here, trading it in for QTP. If you don't have a whole lot invested into WinRunner yet, and you don't need to test in environments exclusive to WR, this might be a viable option for you. If you have thousands of WinRunner scripts, this probably is not the way to go.
[*]Add QTP. Given that there will be (is) an integration for WR and QTP, adding a couple QTP licenses may be an option.
[*]Move to the Optane Functional Testing license. You can either purchase these outright or upgrade your WR license to an OFT license. Upgrading a WR license to an OFT license sounds a lot like adding QTP, right? Sure does. But it’ll costs less. 
It's VERY IMPORTANT to consider your node-locked vs. floating schema here. I can't tell you which way to go. You need to look at your lab environment, and how many licenses of which you really need, but there are some caveats to this:
[*]1 node-locked OFT license allows you to have both WR and QTP installed on ONE MACHINE, and a WR/QTP script can call a QTP/WR script, on the one license.
[*]1 floating OFT license allows you to have ONE INSTANCE of WR or QTP active, accessible from MULTIPLE MACHINES. That means if you are in a floating license schema you CANNOT HAVE ONE APP CALL THE OTHER'S SCRIPTS WITH ONLY ONE FLOATING OFT LICENSE. Those in smaller companies need to take this into consideration.
Big confusion: The original information about Optane Functional Testing licenses did not give the impression that there was a node locked option. It looked like there was going to be "out of reach" costs to get into WR/QTP. Mercury is going back to the wording on how the FT licensing schema is being described and make it less confusing.
There will even be a CD install for OFT: It will have both WR and QTP installs on the disk. Expect to see this at the end of Q2 with the QTP 6.1 release.
WR/QTP Comparisons and "In The Future"
WinRunner 7.6 is scheduled to come out next quarter. WinRunner 8.0 is scheduled to be released at the end of the year. Beyond that, yes, there will be enhancements made to WinRunner.
WinRunner | Both | QuickTest Pro |
Classic | Common | Emerging |
| Custom C/S
| Web-Related Environments
| ERP/CRM
|
For both WinRunner and QuickTest Professional, Mercury Interactive will support all currently supported environments with market traction. Examining the environments supported by WinRunner and QuickTest, one can classify them into three groups: Classic, Common, and Emerging.
[*]Classic: environments supported by only WinRunner. Includes client server environments such as PowerBuilder as well as older ERP/CRM applications such as Siebel 5 and 6.
[*]Common: environments supported by both WinRunner and QuickTest. Includes IE, Netscape, Windows, Java, Visual Basic, and terminal emulator (“green screen”) applications.
[*]Emerging: environments supported by only QuickTest. Includes .Net; newer ERP/CRM environments such as mySAP and Siebel 7.x; and Macromedia Flash.
Mercury Interactive is committed to providing ongoing support for WinRunner in all Classic and Common environments, and is committed to ensuring that QuickTest works in all Common and Emerging environments. This means that, for instance, when a new version of PowerBuilder is released and gains market acceptance, Mercury Interactive will build support for that new version of PowerBuilder into WinRunner. When a new version of IE is released, Mercury Interactive will build support for it in both WinRunner and QuickTest. As new versions of .Net, SAP, and Siebel are released, Mercury Interactive will support those environments in QuickTest. This level of environment support will continue through 2003 and beyond. Mercury Interactive’s goal is to ensure that customers can continue to realize the benefits of using our functional testing solutions in their existing environments as these environments evolve.
QuickTest Pro and...
...TestDirector
The integration of QTP and TD is the same as it is for WR and TD. Test Sets, Test Runs, etc. are able to be created using QuickTest Pro scripts. Since TD can handle both WR and QTP scripts in a Test Set, both can be in the same run.
...MS Excel
Just like you can create data tables using Microsoft Excel for WR scripts, you can do the same thing for the QTP data driven scripts that you will create.
...Databases
According to Mercury, database testing via QTP is equal or better than via WR. QTP has:
[*]Enhanced ODBC database import engine.
[*]Provides same DB verification wizard that is in WR
[*]Open extension of VB engine (COM based replay engine: can make direct calls to ODBC db at the object level)
Conclusion
There was a question about when to use one over the other outside of a scripting preference. QTP has reusable actions, icon based script, active screen, and an integrated data table. It is really up to the individual and how your environment is going to get set up. Those that are new to automated testing may find QTP easier in the long run. According to Mercury, many of the “lessons learned” from WinRunner have been incorporated into QTP.There are certain environments that WinRunner won't be able to go. This may be a matter of business decision or simply WinRunner's architecture. The impression that I got from my conversations with Mercury was that they have no intention of abandoning WinRunner or its users. Mercury is responding to market conditions where there is a greater focus on QuickTest Pro. So you may have to use a QuickTest Pro solution, but you won't be forced into phasing out WinRunner.
Which way should you go? Again, that depends on your environment. If you have been using WinRunner and now you find you need QuickTest Pro, there are a number of upgrade paths available. You'll be able to trade in licenses, add, convert, etc.
No comments:
Post a Comment