Just recently I have found a quite annoying bug in the QTP interface for Table checkpoints.
The situation arose when I decided to use a table check point to evaluate the data in one cell of a table in one of my company's applications presents as a work queue for the application users.
And instead of relying on QTP to evaluate the status of the checkpoint, I wanted to evaluate the result of the checkpoint and report into the results set a more meaningful pass/fail criteria. My testing experience is grounded in the manual portion of my field so I can be a bit wordy about pass/fail criteria.
So...I built code similar to the following psuedo-code snipet:
If Browser("App.com).Page("WorkQueue").Check (CheckPoint("StatusVerification")) = True then
Reporter.ReportEvent micPass, "Hooray it worked","Status Changed!"
Else
Reporter.ReportEvent micFail, "BOOO it failed","Status Did Not Change!"
End IF
Now the psuedo-code snipet above works just great...UNLESS you want to go back and review the checkpoint properties. The only way to get at them is to rightclick on the check point...HOWEVER..with the presence of the If statement, all of a sudden QTP has no idea that code represents a checkpoint.
So instead of evaluating the checkpoint directly, I have to store the checkpoint value into a boolean variable and then evaluate that instead...
GRRRR--<mumbles curses about Mercury under her breath>
posted @ Wednesday, June 20, 2007 8:44 PM