I read some of the threads handling the issue of which tools are best for .NET testing. But what about the companies strategies for the future?
What will happen to those tools when we have Longhorn, when we have Windows Presentation Forms, and whatever will happen in the future.
We invested into WinRunner a few years ago and already find out it will never support .NET.
Can anybody give me some hints how to avoid a dead end in the future? Appearently just asking them isn't enough.
Thanks All in Advance
Every tool you invest in has a limited life and will be replaced. What is the "ultimate" today will be old news soon.
IT is growing and Fast Moving - we have to select the changes we move with.
I have not failed. I've just found 10,000 ways that won't work" --Thomas Edison
The more things change, the more they stay the same. Think of it as an opportunity to keep busy. If everything remained static then you would soon be finished testing and there would be nothing to do. I have been in this racket for about 40 years and still going strong. One of the good things in the Microsoft world is compatibility. When you do your work through a Windows interface there will be no major impact on the testing side other than some comparitively small effort to update to the environment. It really hasn't been that volatile, and most of the old adages still hold true today.
As an amusing aside, we still run test suites with an old copy of Visual Test, which can be made to recognize any .net object for which there's an MFC equivalent. Right now, it's the only thing I've got that works on 64-bit OS running a 64-bit app.
Visual Test was allowed to die years ago, despite it's technical superiority to Winrunner, QTP, and so on. It wasn't priced high enough to make anyone any money.
We found the same thing when we moved to C# a few years back. Contacted Mercury and asked about .NET testing and got told to buy QTP. No upgrade path, no discounted pricing since we were already customers... just a big F### off!
So I took that opportunity to review new tools. Not just from Mercury, but from all the big players (and a few small ones too). We ended up feeling betrayed by Mercury so much that we automatically gave them a few minus dings in every comparison category to re-level the playing field.
Compuware had nothing when C# first came out, nor did Segue. Rational was at least willing to talk to us, but didn't have much of an offering. Mercury had QTP, but documentation back then was worthless (as I'm assuming it still is). Capture/replay was decent... and those screen scrapes were oh so pretty to show managers, but not really helpful.
Then we ran across TestComplete. A $700 tool from AutomatedQA. How was this ever going to work? It's a full 1/5 of the cost of our best negotiated price for WinRunner??!?!
Let me tell you it works like a champ! I could see more data about every type of control under the sun! I can run unit tests on developer code, I can modify the state of the app on the fly and then test those new state.
This thing is slick!
The point to remember is there are plenty of tools out there... don't be afraid of the change. Embrace it. You may end up better than were a few months/years ago!
About Winrunner vs QTP. I worked at a company with 5 Winrunner licenses, and we were also shocked to find out that it didn't have support for .NET but QTP did (with the add in) This did make us a bit angry as more and more .NET app testing came up, but we were able to work with our Mercury rep and get an agreement to replace our Winrunner licenses with QTP licenses at no additional cost, so we didn't have to buy QTP, we just keep paying our outrageous yearly maintenance fees. If anyone is in the same position, maybe you can give this a shot and work with your rep. They seemed used to being yelled at on this issue.
This worked well because QTP was a better tool (for our needs, not necessarily for everyone). Aside from being able to test .NET much more thoroughly, I loved that the QTP playback engine was faster, and it was easier for some people with less experience coding to jump in and create valid tests. It also allowed me to do a lot more with file handling, now that I had the full access to the VBScript file object, much quicker than trying to code stuff in TSL for those of us with more VB than C in us. These differences made it worth the switch to me even though I had years of investment in 100's of Winrunner scripts I had to rewrite. Mercury hasn't announced an end of life time for Winrunner, but it does seem that their focus on future development is with QTP instead of Winrunner, so your probably good for a few years at least with that if you can afford to go with Mercury.