Your e-Business Quality Partner eValid™ -- The Web Quality Suite
Browser-Based Client-Side Functional Testing and Validation Page Timing/Tuning Transaction Monitoring. WebSite Spidering & Analysis and Realistic Server Loading.

eValid -- Making a Script Invulnerable with Structural Testing
eValid Home

Background
A typical scenario we often see is that you have a script that used to used to work and then, suddenly it ceases working. Clearly something changed, because a newly recorded version of the same script on the application worked OK. So, that's a true regression and the FAILure is a valid regression signal.

But evidently there was no visible change in the application, only some changes in the index values at which some page features were located or possibly some value in a visible text field. Re-recording the script re-established the index values and other parameters and the new script worked.

Making An Existing Script "Invulnerable"
There is usuallya way with eValid to make a script that will in the future be insensitive to that kind of a change...so that your test will PASS by tolerating that location change.

Here is the outline of that passage of the script.

  1. Identify some fact about the spot in the application (using PageMap to help) that will be invariant over time. Call that spot the "fixpoint."

  2. Do an IndexFindElement to locate the current value of the index on that fixpoint. That index -- which may vary as the application changes/evolves -- will be the base for subsequent steps.

  3. Move up or down from the fixpoint so you know you are paying attention to the right page element -- the precise one that will receive the click. That location will always be in the same position relative to the fixpoint unless the page changes structure.

  4. Force the target element to be in focus. This may include using the IndexElementEvent command and possibly adding some Delay 10's to give the JavaScript time to settle.

  5. Now send the click event to that element, which you now know is ready to receive the event, probably with an IndexElementClick command.

  6. Start a synchronization loop that waits for some fact from the NEXT page, so that you don't get out of sync at some future playback step.

Such a passage now will be insensitive to the particular location of that fixpoint, even when updates to the application move it around over time.

Challenge Offer
What we can offer is to provide you with one sequence like what is described above.

Once you have one of these passages set up it is easy to do more of them because it is basically the same passage, with only the fixpoint changing.