Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

• Can I get page component timings from eValid? -- Page component performance data details.
• We want to include eValid in our own product -- Possibilities for OEMing eValid are discussed.
• Can your SQL interface be used in monitoring? -- Using the SQL feature in eValid.
• Multi-user Simulations of REAL AJAX Interactions -- Why multi-user AJAX apps run OK.
• eValid operating with Web 2.0 and AJAX applications -- Pointers to business white paper about AJAX testing.

• Has eValid technology been patented? -- eValid patents detailed.
• Do you think eValid is ahead of its time? -- Prognostications of a sort.
• Why is the pagemap so slow sometimes? -- Performance of PageMap on very large pages questioned.
• How does eValid treat JavaScript errors? -- Internal JScript error detection and reporting.
• Does adaptive playback work when the ID tag is blank? -- Adaptive playback without ID tags may not work.

Side-by-Side Viewing of Mobile Devices

One of the things we've found in our work with testing various mobile devices is that it is often very convenient to be able to see the same page delivered to two different devices in a side-by-side comparison. The visual impact of the changes can be enlightening.

It turns out that this is relatively simple to do, using a special launch page and custom playback script. In the script the UserAgentString is set to a device and a sub-window opens emulating that device. After the two [it could be more, if you have the need] sub-windows are opened eValid pauses playback, leaving both sub-windows open and live.

In this state, you can manipulate either of the two emulated devices in any way you wish, and see what the server renders in response. For backup, you can see the server response for the same page request in the parent screen. Here is a screenshot of Two Smartphones (iPhone and Samsung Galaxy) and of Two Tablets (iPad and Samsung Galaxy Tab). Both screenshots show the same page all three ways. And you can see the UserAgentStrings directly.

Here is the full writeup of how this is done, including a sample script and a typical parameter setting file: Side-by-Side Comparison of Two Devices. Sample screen images are shown in Side-by-Side Sample Screens.

Selected User Forum Posts

Beginning in mid-2010 we have directed all technical support questions to the eValid User Forum. We have learned that when one user has an issue, all users can profit from the answer.

Here is an additional selection of some of the posts that we think would be of general interest.

• Can your structural testing test "anything"? -- The limits of structural testing are detailed.
• A High BU Count During Monitoring -- A discussion of the impact on timing accuracy with heavy CPU usage.
• Can eValid collect data similar to Google Page Speed? -- Comparing client-side and server-side timing data.
• Synchronize Very Complex Pages -- The art of AJAX synchronization explained.
• Frames With A Lot Of AJAX/JavaScript -- How and shy eValid handles AJAX frame-intensive pages.

• "Mouseover Recording" Turned On and Off -- Pros and cons of the mouseover recording option.
• Tell me about how eValid can suppress popup modal dialogs? -- Popup handling explained.
• What is the difference between MatchString and SyncOnText? -- Face validation versus internal DOM synchronization discussion.
• Can you tell me more about eValid's architecture? -- Details about how eValid is built.
• My recording of an AJAX application -- Discussion of AJAX test script durability.

Mobile Device Testing

There has been a lot of interest recently in how to handle quality issues (content, performance, server capacity) for web applications that run on mobile devices. From the eValid perspective the main issues work out to these:

• Device Simulation: Using the eValid SetUserAgent command to set the User Agent String (UAS) so that the subsequent browser activity is reported to the server as if it was being requested from the specified device. eValid does this without needing the actual hardware and software! The server responses to client-side user requests made in this way behave as if it was talking to the mobile device.
  

• Content Validation: Once a script is running, you need to validate that the eValid rendered output matches what you expect in the actual device. Here is a Rendering Comparison for Common Devices Vs. Device Emulator. As you can see, other than the screen size, the rendering by eValid is identical to that for the mobile device. This confirms that evalid is rendering your mobile application correctly.
  

• Functional Testing: To illustrate how this works we ran an experiment that applied a simple test to 100 Mobile Devices, and recorded download sizes and times for each cases. A sample of that data is shown here, with some Selected Screenshots of how the server content varied as a function of the different devices and software versions simulated (with download byte counts for each device shown).
  
  

  The most interesting thing we saw was that the asymmetric ratio of Download Bytes vs. Download Time, which illustrates that some servers are not prepared to deliver mobile content to every kind of device.

• Server Loading: Functional tests lift easily to a server loading context, with multiple eValid instances (we call them Browser Users or BUs) working in parallel to create the load. This is illustrated in the experiment that we ran to drive a mobile application from a simulated smartphone up to 1,000 BUs -- up to 1,000 simulated users. The resulting
  Chart of Derived Internal Response Times shows that this particular server began to have a problem beyond ~200 simultaneous users.
  

The thing to remember is that eValid can effectively drive mobile devices that support web applications perfectly well, and can impose realistic load levels sufficient to identify bottlenecks.