I have been recently tasked by my tech lead with two things while progressing with building our test suite in QTP. These are:
1) Begin to try and use a more “tool-based” rather than a “progammer-based” response to challenges in QTP.
2) Sort of how to best make use to recovery scenarios in QTP.
I agreed, of course (since these are associated with my merit raise goals), and so far, it’s driven me nuts. Seems QTP never wants to do things the way I want it to. It has done some very cool things when combining regular expressions with descriptive programming for me, but I’d still rather get at the object I want via the XMLDOM and do whatever I want that way. Every time the tool tries to abstract you from something complex, some amount of fine control is lost. Ah, well, I’ll keep plugging away at it.
For the second item, I have been trying out the recovery scenarios in QTP. I can honestly say that they blow…and I mean goats…nickel a herd. This is one time when the tool based approach isn’t terribly useful. I find the VBScript On Error/Goto 0 approach far more useful to catch and handle granular errors. I have also figured out that the recovery scenarios REALLY S-L-O-W down the test run. If you use more than a couple of them, you see a drastic degredation in run speed. We are just testing, after all, so one must ask if speed is important, but I mean it’s siginificant enough that speed becomes an issue. There is one very handy function in recovery scenarios that I like, though: upon a trigger event firing, you can force the machine to reboot. Now, it won’t restart the next test, but at least you can recover from a drastic crash. I suppose I could write something to start over after the reboot…hmmmm…
For this, I am afraid the programmatic approach is still better….have to get credit for the merit goals somewhere else…..
On a lighter note, the band has its first show this week…wish me luck!
