RO vs. the QTP Shell

Update: this is an article from the old site that wasn’t transferred to the new one. So here it is:

In past few days, the question whether it is “Kosher” to change the run-time properties of the AUT (application under test) was given new life in SQAForums (e.g. here). It’s a tough question, that calls for serious discussion.

On the one hand, messing with the application’s RO objects has no testing value (not emulating user behavior, backstage behavior should be tested via unit-tests), it could cause serious bugs, and could miss UI bugs a user would have encountered. I think this opinion is quite easy to understand.

On the other hand, when done carefully and selectively, setting RO properties can give us a robust way of doing certian tasks, that could otherwise fail our script. Thus, while not having any testing value by themselves, these task could safely get us to a position where we could do some real testing.

I side with the latter opinion, and I think an example will illustrate why:

Say our application has some input fields, divided among various tabs, residing within a tab-control. QTP doesn’t recognize this tab-control, and after many attempts to solve the problem elegantly, it becomes obvious that the only method that will work is TabControl.Click X Y.

Now, this sucks, for two main reasons (beside being an ugly solution): It tends to break (Click events are often block by focus shifting, slow system behavior etc.), and it is very VERY demanding from a maintenance point of view (just change the tab-order, add a new tab, change the resolution or the font, and the script breaks). So, this is unacceptable.

OK, so we try thinking outside the box, do a littlie investigating, and find out that when the user switches the active-tab, the tab control’s inner object change its ActiveTab property to the new tab’s index. After a little creative fiddling, we learn that the process works the other way as well – changing the property via QTP, makes the control bring the relevant tab to the front. It suddenly seems very tempting to just set the RO property whenever we want to switch tabs.

Here comes the “carefully and selectively” part (which is REALLY important): we make damn sure that setting the object’s RO property doesn’t break anything. We ask the programmers, run a few tests of ourselves, and after a while, we become confident that no new bugs will be caused by this. Moreover, we ask ourselves if we could miss UI bugs due to working backstage, and answer a reasonable NO (since any bugs will cause the next step of the script to fail).

At the end of the day, we can then decide that tab navigation will be done via RO manipulation. We can run through the tab collection, find the tab with the relevant name (By looping the TabControl.Object.Tabs collection), get its index, and switch. It doesn’t test the tab control, but it makes sure we’ll get to the right tab, where we could rip the application apart, good-old-fashion QTP style.

So, to sum-up, we gained:
A. A much more robust script (no .Click breaking the script)
B. A generic script (serves multiple systems with various fonts, resolutions etc.)
C. Zero-maintenance growth and change (handles “out of the box” New tabs, different tab ordering, different tab layout)

We paid for it with:
A. VERY small possibility for missing tab-switching UI bugs due to not actually pressing the tab control.
B. VERY small possibility for creating new tab-switching bugs due to messing around with the RO objects.

And this seems like a pretty good balance to me.

Just to be clear – I agree we do need to be selective and careful about applying this methond (e.g. NEVER on a data-grid control), but we shouldn’t abandon it all together.

You can read more about RO manipulating techniques in our article about automating custom controls.