First, Smart Identification (SI) is an algorithm within QuickTest that kicks in when, within the code and repository, two elements look the same to QTP. SI then takes a peek at the the object in question, in an attempt to sniff out a property to distinguish an element from its look-alike cousin. If it finds such a property, it will let QTP know what it should be doing with that element. In a nutshell, it’s doing what the tester should have done in the first place: Looking for a good, unique property of an element, so that QTP is able to take a look at the script and immediately know which object on the page it’s supposed to be carrying out the task at hand on.
So getting back to the question at hand, the answer is ‘Yes’, because it can be useful, particularly to someone not particularly familiar with the ins and outs of QTP, ie. a novice, who may not know to how or when to employ the use of descriptive properties. It can also help out as a helpful reminder in case of an oversight.
And the answer is ‘No’, because the experienced tester should have a feel for when and where to properly describe all the elements used in their test. It’s also a bad idea in case a tester does not know how to read the results correctly, and assumes because their script is ‘working’, they did everything correctly.
In the end, the usefulness of Smart Identification probably depends on the experience level of the tester more than anything, rather than being a black and white issue.
Rex Black of J9 will be presenting on Performance Center at the Seattle Vivit Meeting on Monday, May 9th and J9′s Dave Hoenig will be speaking on BSM 9 at the Pittsburgh Vivit meeting on Tuesday, May 24th. Both events will be sponsored by J9; send an email to [email protected] if you are interested in attending either meeting.
While working on my current project I have been writing programs that test the functionality of our clients upgrades they are making on their main client database. Now, keep in mind that when companies re-write their applications and databases…they have two environments. They have their LIVE and they have their TEST. I use the TEST environment very frequently but, when I write a program that does not save information I test it in both. This week I ran into an issue, one that completely blew me away. It seems that its always the little things that aggravate you the most.
Once I was done writing my code I tested my program in our clients test environment which is accessed through Internet Explorer. Worked like a charm, on the first try even! In the programming world, that does not happen very often. Anxiously, I switched over to their live environment which is also accessed in Internet Explorer. I was not so lucky this time around. This code just worked, flawlessly, but now something is broken. By broken I mean every text field, check box, and button I was verifying would not be recognized by QTP.
I quickly go back to the test environment and run it again. Unbelievably, it fails in this environment as well. Right away I knew that it had something to do with switching the applications. The issue that perplexes me the most is that when I switch between test and live environments, all I change is ONE letter in my URL.
With this in mind, when using QuickTest Professional and you are switching between environments that use the same interface (like Internet Explorer), always make sure to close IE completely and do not simply just change the URLs. It will save you time, energy, and your sanity.
J9 Test Asset Developer
One matter which appears frequently when using QuickTest Professional is that of objects with dynamic properties. The dilemma: QTP uses properties to identify the objects, and if those properties change, the object can no longer be identified in the Object Repository.
Recently I had an application that had a button that toggled its text label from “Billed” to “Unbilled” when clicked. The inexperienced tester will put another, “Unbilled”, object in the Object Repository, thus creating two objects that point to one thing on the screen. This is a hackish and inelegant workaround which will suffice if you just don’t know what to do.
But what happens if you want to verify that the label changes when clicked? You have a problem now, because your test will always pass, whether the requirement has been met or not.
In this case I changed the text label to a regular expression so that it can match any label I allow it to. To do this, just open the OR and click on the property that contains the text label. An icon of a pound sign within two pointy brackets will appear. Click on it and the Value Configurations box appears. Make sure the variable type Constant is selected and clear the edit field. Then check the “Regular Expression” checkbox and put in your regular expression.
In this case, I chose the following:
[UB][ni][bl][il][le][ld]+
It works thusly: the first character of the object is either a ‘U’ or a ‘B’. The second character must be an ‘n’ or an ‘i’, etc. We will note that the order of the characters within the square brackets is significant; we are essentially spelling both words out, with each set of square brackets containing the next letter in the respective words. So the two words we are looking for are “Unbill” and “Billed” with a plus sign appended to match the remaining characters in “Unbilled”. This is not the perfect regular expression, but it is specific enough for our needs. However, if a button is added with the label, say, “Unbillable”, I will have to make my regular expression more specific.
J9 Test Asset Developer
On my current project, I have been updating business components that were recorded against an Oracle platform with a JAVA presentation layer. Initially, due to some object recognition issues with the Oracle add-in we were forced to use just the JAVA add-in by itself.
Since these component recordings the client has implemented a patch to their Oracle instance, that has “corrected” a lot of the object recognition issues that we were having. Now we are able to use the Oracle add-in thus enhancing QuickTest’s functionality against the Oracle forms.
We originally encountered many aggravating issues with using the JAVA add-in only, for example all edit field entries were being recorded with the same object name, and all were using the SetSecure method opposed to the Set method used to enter data.
Once the Oracle patch was implemented, one problem I encountered was that I was unable to record an action that required clicking on a sub-tab called “Collections.” This tab was to be activated in order to interact with the fields it contained. Normally QuickTest has no issues at all with selecting items within a tab strip (in other environments), but on the Oracle environment it simply would not register. I “spied” on the object and found no identifying characteristics except for the name. With such a powerful identifying trait why would QTP not recognize this action when recording? My first inclination was to do Low Level Recording. However, this is only used as a last resort so I decided to try adding the tab to the repository and added …OracleTabbedRegion(“Collections”).Select to my code.
Ultimately, this was the correct fix. It is important to remember or search through the vast amounts of objects and methods when working with advanced scripting. A little extra effort can truly enhance the quality of your work.
J9 Test Asset Developer