You have just discovered that QTP does not offer explicit support for synchronization with asynchronous browser script execution , as well as websites with AJAX support. When QTP considers the page to be fully loaded, the JavaScript handlers still actually work, possibly updating the HTML code used for that page, and QTP accesses the GUI at an early stage.
readyState is a good idea, but it's usually easy to find cases where it doesn't work well enough.
1. The best solution is to synchronize the busy indicator of the application , for example, a progress bar or an activity indicator.
Unfortunately, waiting for a busy indicator means that the busy indicator is always displayed, but many applications only show it if the process takes a lot of time (more than 2 seconds, etc.). Then it quickly becomes a little messier than expected.
2. If the application does not have anything like this, you can often help yourself by synchronizing on some “ready-made” indicator , for example, “expected field appeared” or “OK button is disabled.” This often requires a specific solution for each context, if not real “ready-made” indicator (which usually does not exist).
3. In many projects, automation users can get a busy indicator, which is built into the application only for them. . Although this does not create a lot of effort for developers (since modern applications have a centralized message manager, so switching to busy is inactive and vv can be easily monitored centrally), this greatly simplifies the amount of work required for synchronization.
Therefore, if possible, try contacting the developers and get them a representation of the property (a variable, a memory-mapped file, a semaphore, whatever they wish), which can easily be tested by the "synchronization" routine of the test robot. (Hint. To be able to distinguish between two “ready” states even after the “no” state is “busy” between them, it may be useful to get a consistent “busy state account” in addition to the “busy state icon”, so you can request this in in the same case.) Then, all synchronization problems are a defect in the application, since it obviously does not support the correct signal.
Update For applications based on the de facto "standard" structure, you can find ways to implement synchronization in a general way.
For example, for JavaScript applications, I was able to create test equipment that transparently reports the flow of events in QTP, which is used there to wait "long enough", allowing you to set up special calls, similar to the control points that are waiting for certain events (especially "click", and for applications running AJAX roundtripls a la Java Server Pages, "ajaxstop" events) that must be executed before continuing.
This turned out to be extremely useful, because it is often very difficult to get the developer to implement any support for test automation, and synchronization based on the graphical interface (only through the state of the test object / existance) is sometimes not enough if the application performs asynchronous requests in the background. It also eliminates the need to examine synchronization parameters for each GUI context, which can be extremely time-consuming and / or unreliable.