Your e-Business Quality Partner eValid™ -- Automated Web Quality Solution
Browser-Based, Client-Side, Functional Testing & Validation,
Load & Performance Tuning, Page Timing, Website Analysis,
and Rich Internet Application Monitoring.

eValid -- Playback Synchronization
eValid Home

About Synchronization and Initial Browser State
The most common forms of de-synchronization are due to changes in the initial state between when a recording is made and when you command eValid to play it back. These situations are often caused when:
  • The recording process changes the initial state to some intermediate state, so that the playback doesn't start in the same state. For example, the recording process establishes a cookie.
  • The playback process alters the initial state to some new state, making a second playback impossible to replicate.
  • A second, parallel playback starts with the incorrect initial state due to the modifications made by the first playback.

The general rule is is this: for eValid to successfully modifiy the browser state to validate operation of a website, it MUST start in a known state.

Introduction
During test script creation using the real-time recording mode inserts "Wait nnnn" commands to account for user think time. eValid has a built-in HTML page synchronization based on sensing of the "document complete event" within the eValid browser. In addition to this synchronizing mode any available inter-command times also serve to help synchronize playback. This page describes how to assure synchronized playback when the usual methods do not work perfectly.

Need for Synchronization
It is a good practice to make sure that a recording maintains synchronization with the pages that the server is delivering to the browser. If playback is not synchronized subsequent actions on a page usually are not meaningful.

When scripts are intended to be used with multiple browsers, e.g. in eValid LoadTest operations, the need for synchronization is acute. This is because the response time from the server can be very much longer than when the recording was made. (This is often the point of a LoadTest experiment!)

A fully synchronized (or self-synchronized) test can be lifted from singleton playback to LoadTest operation without modification.

Solution Outline
The basic solution is to synchronize playback of slow-loading or slow-availability pages using one of eValid's playback synchronization commands. These commands include the Validate and Synchronize on Text String and Validate and Synchronize on Screen Rectangle capabilities.

These commands can both be recorded into the script during the script creation process. During recording you reach them with the Record > Validate > & Synchronize >... pulldown. It is generally not a good idea to try to edit these commands into script manually.

In effect use of these synchronization commands is a kind of "recording protocol" which forces creation of a fully self-synchronized script. As mentioned, such a script is essential for testing of websites for which the normal HTML page synchronization may fail.

The protocol used is simple: sync > action > sync > action, etc. Every activity first synchronizes on the screen to which it applies and then takes the action after the page is known to be ready for it.

Identifying Fail-to-Sync Problems
The acid test for self-synchronizing scripts is to observe that the script fails when the Wait Time Multiplier is set to zero and/or when the script "plays ahead" of the response it is intended to produce from the server.

You can tell if a script has played ahead if the test runs to completion but the browser screen shows an intermediate page. Usually what happens is that a page arrives too late, timeouts take over, and the script playback proceeds -- without coherent meaning -- to the end.

How to Confirm Self-Synchronized Script
The best test for the self-synchronized property is to run the script with the wait time multiplier to zero. You know that the script is self-synchronizing if it always succeeds even when the load on the server (the delivery time of the pages) varies.

It is good practice, before promoting a script into LoadTest scenarios, to confirm that it is self-synchronizing.

Pages Where Fail-To-Sync Often Occurs
Pages can be slow to be ready for access and/or use for a variety of reasons. Some of the more common reasons are:

Minor Warnings
We have seen a number of cases where synchronization fails because of a bad interaction between the Draw Visible Outline option and the images on which the synchronization is supposed to occur. This option is normally intended to inform the user that "something is happening".

To show the blinking outline eValid has to read from the current image, save the pixels where the outline is going to go, draw in the pixels for the outline, wait for the blink interval to elapse, and restore the original content saved from above.

In case the screen image is changing dynamically there is a slight chance that synchronization will fail when this option is turned on. If you notice this -- and it is quite evident because your syncs will fail! -- simply turn this option off.

Another problem occurs when a page has an unpredictable up/down scroll possition. The solution is simple: position the cursor in the scroll aread and record a HOME or END to force the scroll bar into a known position during playback. You may also follow a HOME by a number of Down-Arrow clicks, or a END by a number of Up-Arrow clicks.

AJAX Synchronization
In AJAX applications synchronization probably needs to be done using detailed information about the page and how it was implemented. See the list of available commands in the Synchronization Mode Summary.