| || |
Converting QTP to CodedUI
I did not see a Coded UI section so I posted here...
We have over 50,000 lines of QTP code that we need to convert over to Microsoft's CodedUI autoamtion tool.
Does such a beast of a conversion tool exist??
Just a little sample of what kind of code we want to convert:
None of the code is "record & playback". Even built in methods such as .Set and .Click are replaced with our own user defined methods.
At the start of the run, we using input dialog boxes asking tester which test settings to use (such as printer to use, environment to test, run in attended or unattended mode - does Coded UI even have these modes?)
Our scripts take screen shots anytime there is an error and write the failed steps to the print log, and all executed steps to Word docs.
Sometimes we use the "Visual relation identifier settings" in the OR.
We use regualr expressions to identify objects.
Sometimes we use descriptive programming.
We use CreateObject often (just a few examples) :
We use CreateObject("Scripting.Dictionary") for almost all functions to pass in as an argument.
We use function files and use one to store all variables.
We data drive almost all of our test cases.
Our test cases are functions called by another function that evaluates it (example TW"TestCase_1" )
We use flow control (IF/ELSE. Select/Case, DO/While and all that good stuff).
So how easily can it be done?
I don't think CodedUI usage is high enough for someone to have made such a conversion tool.
Going from vbs to CodedUI's object oriented C# isn't really a plug and play kind of thing. QTP is a functional testing tool and CodedUI is more for unit testing and there are a lot of architectural differences. You'd largely be starting over from scratch.
Wow. There's a huge project. But it could be a fun challenge, too.
Identify each unique QTP function. These could be standard vanilla functions in QTP or homemade functions of your own creation.
For each function in Step 1, create an equivalent function in CodedUI. Manually, of course. Get your best coders working night and day on this.
Write your own conversion tool, a parser that evaluates QTP scripts, line by line, and replaces the QTP functionality (from Step 1) with the CodedUI functionality (from Step 2). This should not destroy the original, but should create a new auto-generated script for CodedUI.
Step four: Test each auto-generated script and ensure it runs correctly, no errors, and executes the test the way it should. Compare with the QTP version to ensure accuracy (not that QTP is necessarily better, but I'm assuming your QTP scripts are all good, working, effective scripts or you wouldn't bother converting them at all, so they should be the baseline against which you test your generated CodedUI to make sure it works). There will probably be some coding effort here to fix scripts that don't quite work - maybe this is a chance to enhance the conversion tool to handle the anomalies.
Step five: box up your conversion tool and sell it to anyone else who tries this, and maybe one day you'll make enough revenue to pay for your big conversion project - turn your conversion effort into a profit-generating side business for your company and then ask your boss for a big raise. (wishful thinking)
"The last 10% of any software project will take 90% of the budgeted time. The first 90% will take the other 90%"
With porting from any tool to another one, you'll find that most tools are sort of designed with non-portability in mind. There are no agreed upon standards, and tools are purposely designed that way to make porting much harder. While you mentioned you abstracted away the .Click and .Set methods, however, that doesn't save too much work. As any mass replace could easily solve that problem.
What's more problematic is the locator strategy (does QTP and CodedUI use same locator types? I'm sure there are some objects that do when you have a unique GUID, but I'm sure you'll have many that have hierarchical relationships that do not have the same relations when you are working with Proxy Objects that use accessibility interface (QTP) vs. Real objects using a built in automation API (Coded UI). You'll probably not get a 1-1 correlation in each. But you're probably better off using redoing the locator strategies, when you have lower level hooks you have better and more consistent locator strategies you can use anyways.
Also going from VBScript to .Net isn't as easy as it seems. Most of what you've done in VBScript, you'll immediately want to rethink with a true Object Oriented programming language. For example, the whole exception handling in your framework. Now that you can do proper try/catch, would you really want to port your framework, or just build a new one that's well designed from the ground up?
Then there is all the automatic stuff QTP provides you. For example, the idea of implicit waits. When you locate an object in QTP, it will implicitly wait for the object for you. That is actually a lot of different steps. (Checking it exists, getting an object reference for it, waiting to make sure it's responsive, etc...). You'll find that there are places where you'll have to expand out statements where you have dynamically created elements, and simplify things that have easy object level hooks to. Of course you can try to build wrapper objects to handle all that stuff QTP does, but you wouldn't want to because you'll want to just use exactly what you need to keep the performance of the test running as fast as it can.
In my experience, when changing from one automation tool to another. Usually only about 2 or 3 layers of a proper 7 layer framework gets preserved. (business logic, data, and reuseable flows) Usually the object recognition, exception handling, reporting, and the low level logic layers are completely replaced and rewritten from scratch. (although in theory reporting layers shouldn't need to be rewritten, in practice most people use too many tool specific code in their reporting layers)
Last edited by dlai; 02-11-2014 at 07:49 AM.
Your two biggest challenges will be moving from VB to a strongly typed language. To code the conversion would mean writing a large amount of code simply to deal with data types. The second is the UI Map concept in Coded UI. It will not matter if you use DP or the OR you will have to create the maps by hand. In a nutshell there is no conversion path, only a complete rewrite of your automation. There are other considerations as well. Are you running builds from TFS? You will need to have build definitions for the coded UI in order to run the code remotely and this process is 100% to MTM, it's lab set up, TFS controllers and agents. The effort is HUGE and involves much more than just the code...
Lines of code does not really relate to the effort you have before you. You might want to present your estimate based on number of test cases and the time to convert each one as well as setting up the test environment to run the coded UI.
Also, keep in mind coded UI only works with web applications and is not really useful for cross-browser testing. If cost is driving the conversion you may want to evaluate Selenium as well.
Any Software product does not resemble another one, that is a thumb rule in software industry. Two software products built for same reason from two different vendors will vary a lot from each other but the final objective will be met by both products. If you take example of Apple IPhone Vs Samsung phone they both are phones meeting same purpose but in terms of usage they differ.
This is similar to any automation tool, VSTS Coded UI differs a lot from QTP.
Glancing at High Level for VSTS Coded UI
1. No Robust OR Concept as QTP, but does have a OR concept
2. Object Oriented while QTP is VB Script
3. Supports only microsoft technologies, QTP supports various technologies
4. Compile, Build and run While QTP can run directly
5. Can use multiple programming languages like C#, C++, VB, etc while QTP uses only VB Script
6. Technical support is very less, while QTP HP Technical support is nice.
Overall i think you will have to start from stratch for rebuilding your 50k Lines.
I don't build Software but I make them work better, Testing is a Passion