As some of you may know, I am a Software Automation Engineer using Mercury QuickTestPro as my automation development environment. The company I work for is a web-based business with online application processes. One of the challenges of this online application process is that the business owners like to "tweak" these applications by changing question order, text, and in some cases question sets.
To do this they create different "versions" of these forms. So if you navigate to the website and request a form its possible to get any one of several dozen versions of these forms. This poses a problem for automation because in traditional "Object Repository" automation scripts, QTP must know what objects are going to be on a particular page or not. Historically the way we've dealt with fact is to only automate one version of the application.
Problem with this approach is that we cannot test natural navigation to the application from the website's homepage. We cannot leverage the automation engine to test a new version of the QF. Which results in poor automation coverage of the code base which is deployed into production. So what's an automation engineer to do?
Well, she takes a page from the giants whose massive shoulders she stands apon and comes up with a new approach.
My colleagues here had started the process of creating a new approach to the automation of applications. Basically what this approach would do is instead of assuming what questions would be on any given page of the application, the automation script would ask the Page itself--What questions do you have? and then based on a bank of possible questions, answer those which were presented. Its really an elegant way of handling the problem. Using the Page's Document Object Model(DOM) we can ask it, what questions are you showing? And then respond accordingly.
There was only one problem with this approach. There are times when after a question is answered on a page, several more questions may appear. An example is Address. If the applicant says they've lived at the current address for less than two years, we display a set of questions for Previous Address. So if the automation script asks the page--Give me all the questions you're showing and then fills them out, it wouldn't know that new questions had appeared.
We tossed around potential solutions to this problem for weeks. Should we create an Array containing the possible questions and mark those we've answered??? It seemed like it was a log jam we couldn't get around. Until a solution presented itself from the most unlikely of places--MythBusters.
I know what you're thinking, "What does Mythbusters have to do with writing QTP code?" Well, a few weeks back I was watching an episode of Mythbusters where the hosts Adam & Jamie are testing the myth of the "killer playing card" and they decide to do a build off. If you're not a fan of the show, this is where Adam & Jamie will each build a rig to test the myth. Adam goes off and starts to build a mechanical throwing arm, where as Jamie builds a rig that looks like a miniature version of a football throwing machine. Adamfaces a myriad of design problems while building this really complicated throwing arm. In an aside, Jamie makes the following comment, "If the design is overly complicated it is normally a sign of a weak engineer. Simple designs are best." This is the engineering equivalent of Occam's Razor. (You know..all solutions to a problem being equal, the simplest is probably correct?).
When he said this, a gong went off in my head. DUH!! Make this problem simple..find a simple solution and go with it.
So...Here's what I did. I built two functions. One function fills the page out initially. The second function verifies the questions are answered correctly based on the set of known good answers provided in the script. If the verify check fails, the second function will answer the question again and then set a flag saying--I've changed something on the page and you need to run verify again.
And PRESTO--A version independent platform for testing customer applications is born! And I can run it on any version any time. (grin)
The action that fills out the application looks something like this:
Do Until (blnXSellFound = True or intLoopCount > 10)
RunAction "R_FlexPageFill", oneIteration, blnXSellFound
intLoopCount = intLoopCount + 1
'Putting a Wait statement here to allow hidden questions to appear before running FlexVerify
Wait(2)
If blnXSellFound = False Then
Do Until (blnVerifyChange = False or intChngLoopCount > 10)
RunAction "R_FlexPageVerify", oneIteration, blnVerifyChange
intChngLoopCount = intChngLoopCount + 1
Loop
blnVerifyChange = True
End If
Loop
EDIT--I'll post the code that does the "DOM" inspection and manipulation in a future post. Stay tuned. 
EDIT2--In my haste to post this the other day, I got the names of the Mythbusters backwards. In the interest of "correctness" I have fixed those names in the narrative above.