Checkpoints and points-of-view

Many of QTP’s downsides are due to the inherent tension between trying to be beginner-friendly, to having enough depth and complexity for writing real automation scripts. It’s more than just having too many menus and options – in some cases; QTP induces shallow thinking and bad habits. I apologize for being dramatic, but in my experience, users that were “QTP educated” tend to see too many problems as impossible and possible solutions as non-existent, due to the narrow QTP point of view.

Checkpoints

One subject that suffers from such narrow point of view is that of Checkpoints. Through its friendly, simple checkpoint interface, QTP educates the user to a very one-dimensional point of view on the subject. QTP paints a clear cut, black and white version of the world. Each checkpoint can either pass or fail under a single condition only. Moreover, while the checkpoint is executed, the system halts, unable to respond to the application under test. In the real world, matters are almost always more complex, and need a far more flexible mechanism.

Apart from the technical difficulties, the QTP’s checkpoint mechanism makes us think of checkpoints as a log pass/fail reporter, while checkpoints are so much more. Checkpoints are supposed to be smart decision hubs, which allow us to channel the script’s flow in the most efficient and proper manner, while responding to the “real world” in real time. The QTP’s checkpoint mechanism doesn’t allow us to be smart enough, nor efficient enough to accomplish that.  

I’ll present my own personal mechanism for implementing checkpoints, while comparing it to the inherent mechanism in QTP. It should be clear that not all checkpoints require a custom mechanism, but since it’s important to keep our code uniform and readable, it’s enough that only some do. There are many different methods to implement checkpoints, and mine is not necessarily better than others. The important thing is to free yourself of the narrow QTP view-point, no matter the specific implementation you choose.

Here’s the general structure I use for checkpoints:

iTimer = Timer 'Get the current time

DoTriggerEvent 'E.g. : click a button, submit a form, close a window, etc.

Do

    'Inner code to deal with anomalies.

Loop until (Timer-iTimer>30) Or (AnotherExitCondition=True)

'Here we wait 30 seconds before exiting the loop

If Timer-iTimer>30 Then

    'Code to deal with TimeOut

Else

    'more code to deal with different exit conditions

End if

Dynamic timer

One of the biggest problems with QTP’s checkpoint mechanism is that it relays on static timers. This means that once the checkpoint countdown has begun, there’s no way to delay it, pause it or reset it. As a result, many operations that are salvable by some small action are doomed to fail, since there’s no way to do the needed action until the checkpoint has finished, and has failed. The next example shows how we can respond to a system busy message, by dealing with the message window, and prolonging our countdown:

iTimer = Timer 'Get the current time

iTimeOut = 30 'How Long To Wait

VBWindow("Window").VBButton("Button").Click

Do

    If VBWindow("Window").Dialog("SystemBussy").Exist Then

      iTimeOut = 90 'Longer time-out

      iTimer = Timer 'Reset timer

      VBWindow("Window").Dialog("SystemBussy").Type MicReturn

    End If

Loop until (Timer-iTimer>30) Or (VBWindow("Window").Dialog("Success").Exist)

Redo trigger actions

Every QTP user has seen QTP miss button clicks, menu selections and keyboard inputs because of a momentary CPU spike, or focus lost. While these will cause QTP’s checkpoint mechanism to fail the checkpoint, a custom mechanism can take these into account, and protect the checkpoint from false negatives. In the following example, the checkpoint tries to re-click the trigger button after a while, in case the original click was missed.

iTimer = Timer 'Get the current time

VBWindow("Window").VBButton("Button").Click

Do

    If (Timer-iTimer=20) Then VBWindow("Window").VBButton("Button").Click

Loop until (Timer-iTimer>30) Or (VBWindow("SubWindow").Exist)

Multiple exit conditions

QTP’s checkpoint mechanism allows for only two exit conditions: either the checkpoint timed-out, or the pass condition became true. In the real world, exit conditions tend to be more complex, and include several different options for pass and fail. While the inherent mechanism can’t deal with multiple complex conditions (without becoming an unreadable mess), a custom mechanism can do this easily:

iTimer = Timer 'Get the current time

VBWindow("Window").VBButton("Button").Click

Do

Loop until (Timer-iTimer>30) Or (VBWindow("SubWindow").Exist) Or _

    (Dialog("Failed Operation").Exist) Or _

    (VBWindow("Status Window").GetROProperty("message") = "Incorrect Password") OR _

    (VBWindow("Sync").Exist AND Dialog("Incompete Form").Exist)

If not VBWindow("SubWindow").Exist Then

    Msgbox "Operation Failed"

    'Separate treatment for the failure reason, if needed

End If

Non-standard exit conditions

Though QTP has many different types of checkpoints (DB, XML, text, object properties etc.), there will always be that non-standard condition that isn’t covered. An actual example I’ve encountered was about letting the user add a value to a non-standard combo-box (meaning QTP didn’t recognize it as a combo-box). The only way to check if the action succeeded was to hookup to the combo-box internal run-time properties, run through its items collection, and validate the new value was in there.

Moreover, the different checkpoint types mean that combining different conditions in one logical structure can be extremely messy when done with QTP’s checkpoint mechanism.

To sum-up

Any inherent mechanism, in any program, is a tradeoff between the user-friendly interfaces and usability, to the limitations it imposes. QTP’s checkpoint mechanism fails in taking too much flexibility and much needed complexity, while giving too little in return. Even worse, it educates the common user to an over-simplified point of view, while make some real-world problems seem impossible to work through.  However, we can implement our own custom checkpoint mechanism, which costs us small amounts of readable, maintainable code. Aside from the custom mechanism technical advantages, it allows us to view checkpoints as more than simple log pass/fail reporters, but rather as a crucial tool for managing our script’s flow.