We have several QTP test scripts (right now a half dozen, with about another 10 to develop) that validates a reasonably small business workflow, but one that involves several iterations. For example navigating to all products (dynamically defined) on a website, where each navigation starts at the home page and drills down to the product just as a real user does with mouse clicks. The big multiplier: this type of test then further iterates on 40 country/lang combinations. So a script of this nature runs from 8 to 10 hours.
We find it is painful enough to wait 10 hours for Pass confirmation. But what is the real killer is when the script runs for the 10 hours (and while it is running provides no feedback on Warnings and/or Failure messages being logged--bad QC!) and then terminates with 100s or 1000s of failures. In this situation we of course would have wanted the script to terminates hours earlier.
If you have dealt with this dilemma before, what solutions have you implemented? I am new to QC and don't find any configuration to tell it to terminate a test after X number of errors. We are thinking we will have to embed this logic into our QTP framework. Is there some other alternative?
P.S. And suggesting that we run 40 instances of this script is non-started, as we only have a dozen execution PCs which we must share with 3 other large QC projects.
Terry i don't know whether this will work, but then soemthing that came up.
The below is not some QC setting, but needs to be put into your qtp script itself.
The 'run' table contains the data about the test execution, I am wondering is there a way to poll the table and get the execution status at some predefined intervals along with tiemstamp and then decide whether you want to halt or proceed the test run.
I am afraid i cant try this at my current employer as accessing QC data thru API is security issue here..no idea how though or may be it can run outside QTP as well..
but then yes i think there should be an better way to do this within QTP itself...
Keep us posted on the approach that worked for you though...