Sometime in Q2 last year, my company asked me to evaluate what could be a painless migration program for moving our automation test repository into Quality Test Pro (QTP) from Winrunner which we had been using to generate tons of tests scripted across the various supply chain product. Personally to me, a WinRunner veteran, this came as a surprise and just the thought of the enormity of the effort and the costs we had invested over years to meticulously script, maintain and leverage these scripts to certify many a regression cycle shook us initially and more so when we discovered that the HP authorized partner vendor (WinQuick) were not of much help given the accuracy of migration they could promise and the prohibitive costs and time investments we would have had to make to get the old scripts working on QTP. I have been in similar POCs in the past with the most recent one being a migration of our configuration management system (From Borland's Star Team to IBM's Clear Quest and Clear Case), but the automation script migration effort was even trickier, not because we wanted, but just because Mercury was bought over by HP and they in turn decided to sunset WR and focus and consolidate the automated test market with the HP Quality Center which as a packaged solution offers automated software testing, governs QA processes and also can facilitate defect management. QTPsupports keyword and scripting interfaces and features a graphical user interface. It uses the Visual Basic Scripting Edition (VBScript) scripting language to specify a test procedure, and to manipulate the objects and controls of the application under test.
So, we are here today with much of a rewrite and reusing our data sheets in some places where the design allowed us. QTP is a simple to use tool which offers some flexibility but the costs associated and shortfalls the tool in its present form is worth a mention.
a. Descriptive programming in QTP is a pain
b. Improved runtime debugging support for VBS functional libraries was what i was expecting in an enhanced version of the QTP
c. Allow multiple QTP scripts to be open at the same time (like WinRunner having tabs). especially when i have modularized my scripts
d. More descriptive error messages rather than "Generic Error" message.
e. QTP running on a machine with Rational tools almost drains the memory of the box - QTP is certainly not a low resource hogger
f. Not capable of in-memory executions , which a highly priced automation solution of this generation should have provided
g. Support for asynchronous pages. HP could have surely provided a better support for Ajax. If the application had a way to put a wrapper around asynchronous calls so you could determine if the application is still waiting on an Ajax request, that would make testing Ajax web apps much easier.
h. HP should have put some more thought into making the interface to behave like an IDE. (Similar to the way visual Studio works)
i. Open API to call QTP from other tools (for example Visual Studio 2010).
j. There should have really been two types of licenses for QTP. One which can be used only for running the scripts/suites and second which is a superset, used for script development and execution both. Point is, I do not want to block my license for execution only and lose on the ROI on this investment. A developer/execution license set-up would be ideal. We, for example ended up buying many licenses which include the full GUI, but only need to be able to run remote tests. It seems like overkill to dedicate licenses just to run tests.
k. Provide better support for remote test execution. Quality Center could keep an inventory of enabled remote hosts (different from the current behavior today where it just does a scan of the LAN and gives a list of hosts). These hosts would probably have the remote agent running and would be accessible via IP address, not just machine name (making testing across subnets much easier). It would be a very client/server setup, where the clients register with the QC server. If the execution actually occurred through the QC server instead of through the QC client, that would also be nice (although this solution may not work for everyone depending on how your lab environment is configured). The QC server would then send all the remote execution requests to the remote hosts. The schedule would be kept on the QC server so a QC client connection would not be needed to initiate the remote runs.
So, despite all this we have embarked on our journey to migrate and migrate indeed to a state where we no longer intend to do mundane tests manually but leverage the power of QTP
No comments:
Post a Comment