I gave a qtp interview and there i was asked a solution for the scenario....
Suppose there are three edit box which has only one property id which keeps on changing. Now due to this issue you asked development team to provide a property to object which never gets changed and developer gives the property as dev id which will be static...now when you spy the object that property dev id is not visible in object spy but developer says the property is there now how will you automate this scenario and you can't use index for edit box.
wat could be the solution for this.....the interviewer said he has 3 solutions for this but in end when i asked he didn't gave me the answer.....plz help really curious to know the solution for this issue...
Technically speaking, the best solution is to get the devs to add a unique property that's accessible (or do it yourself).
Here are 2 BAD ways of doing it... (most automation engineers will throw up in their mouth)
1) Use node traversals to go up to a parent container that contains both the edit field and it's corresponding label and use that label to identify the edit box. Or similarly, locate all the labels and find a label with similar Y coordinate to identify the element. (VERY BAD)
2) Create a proxy object. This is essentially creating a plug-in for the automation tool, and extending one of their object recognition classes to also include other non-standard properties. (Not as bad, but normally used as a last resort, usually after the automation engineer gets into a fist fight with dev and loses)
Last edited by dlai; 03-02-2014 at 08:53 AM.
I don't have a SAID at this time. It seems like a good question to ask HP Support.
Please let us know what they say if you do ask them. It would be good to know.
Maybe ask HP what property the developers should expose and how they do it so QTP can see it.
Your "dev id" property should be visible (through object spy) in the outerhtml for your WebEdit. You will be able to use Descriptive Programming to identify your field like this:
Browser("myBrowser").Page("myPage").WebEdit("dev id:= someuniquevalue")
You can create a WebEdit in your Object Repository and specify the outerhtml as a regular expression with "dev id=someuniquevalue"
You can create a WebEdit in your Object Repository and specify a custom property called "dev id" with the appropriate value.
In addition to the above:
QTP and its Object Spy will recognise most standard properties of most standard objects.
To access non-standard properties with QTP, use the "Object" Property.
You should also be able to see these in object spy if you change your view from "identification properties" to "native properties".
Quote from QTP Help file:
Accesses the native methods and properties of the object.
The Document Object Model (DOM) is a set of objects that correspond to the elements you see on a Web page. You can modify the appearance and behavior of an HTML element by altering a DOM object's properties and calling its methods.
When you use the QuickTest Object property for a Web object, you actually get a reference to the DOM object. This means that any operation that you can perform on a DOM object, you can also perform by running a <WebTestObject>.Object statement on the Web object. For example, you can use the links property of the Internet Explorer document object to retrieve a link collection.
The Web Object property can be used only for supported versions of Internet Explorer and Mozilla Firefox.
For details on the Internet Explorer DOM, see About the DHTML Object Model (Internet Explorer)
For details on the Firefox DOM, see https://developer.mozilla.org/En/DOM
... just another Tester ...
I was interpreting the question differently. I was looking at it in the way that QTP user tried seeing dev id, but it was not showing up anyplace in QTP. How do we get QTP to see the property that was made public by the application developer.
I don't know how to do that.
In webobjects, you have full access to anything in the dom. So there really isn't a situation where you have hidden dev ids (unless it was hidden by the minification process between test and production builds).
This is more of a problem with native controls. Especially when using a 3rd party control where you do not have direct access to the developers. That's where the technique of writing object proxies can help. But as I mentioned this is considered a BAD way of doing things and should only be used as a last resort. Object proxies are extremely difficult to develop and deploy correctly. It is orders of magnitude of difficulties much harder to create an object proxy than it is to simply create a test hook in the AUT.
The object inspector will only see properties QTP has support for when dealing with native controls. The idea of object proxies is to extend QTP's object recognition to see those properties. This generally involves cross compiling a library in the AUT's native language that has access to that property, then creating a QTP plugin that can recognize that proxy object. It is far easier for the developer to just use a standard MSAA property. It can be as simple as putting a line of init code to append the dev id to the MSAA object name.
Since 'dev id' is a custom property, you should use the attribute key as below:
Originally Posted by a.irvine
Browser("myBrowser").Page("myPage").WebEdit("attri bute/dev id:= someuniquevalue")
The answer provided by you is bit more interesting .Can you give us a example of doing that(Object Proxy)
I haven't done it with QTP before, I've done it once with TestComplete and once with RFT.. not a pretty, and I try to avoid it as much as possible. Only time I've actually had to use it was when dealing with legacy software using 3rd party controls where the developer has left and no one knew how that code actually worked. (so they didn't want to risk making changes to it)
Originally Posted by saikri
HP's public documentation on this is very sparse. HP actually makes a lot of money selling their own plugins, creating your own object proxy is essentially what HP uses to create support for new controls, like the Flex and Java plugins. HP, I believe they call this feature, TEA (Testing Extensibility Api). I did a quick google search, and I found a quick blog post about it, this one describes the process of cross compiling a extensibility add-in to support a custom Java control.
Blogs on QTP Automation: Extensibility in QTP
There is more detailed documentation that's available, but only to those with licenses to the product (which I don't currently have). It's buried in there with the user manual. There are also marketplaces out there for 3rd party controls. Also sometimes the maker of those UI controls will sell separately a plugin pack for QTP and other automation tools. (Sometimes costing even more than the controls themselves).
Each WebEdit has an index. Use the index to write to the WebEdit's...