Abnoxious QTP Bug...a.k.a Fun with Table Checkpoints

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>

  • Share This Post:
  • Share on Twitter
  • Share on Facebook
  • Share on Technorati
posted @ Wednesday, June 20, 2007 8:44 PM
Print

Comments on this entry:

No comments posted yet.

Your comment:



(not displayed)


 
 
 
 
 

Live Comment Preview:

 
«February»
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
26272829123
45678910