IT/QA Solutions for Tough Times

Nobody will argue with the sentiment that times are very tough. But times have been tough before, and somehow we got through them. And then things got better.

In times of budget cuts, hiring freezes and diminished headcount, it makes sense to pay special attention to the "total cost of ownership" for technical quality assurance, monitoring and performance validation solutions, because nobody can afford the costs of lost customers.

If you figure the benefits of gained productivity, ease of use, quickness to good results, overall flexibility, lower infrastructure and labor costs, we think eValid is truly a "tough time solution," where you can get a lot done with little effort, and at a very moderate price. Applying/introducing eValid in your IT/QA department will help cut costs and reap big dividends.

It's something to think about, so let us hear how eValid can be the cost effective alternative that helps your organization remain competitive and be positioned for success.

A Simple DOM Manipulation Example

We have been getting a lot of questions recently about how eValid handles interactions that require pure-DOM operations.

Of course, most of what you can do by constructing an eValid script to manipulate the DOM can be done with a recorded (captured) script, but in some cases there are conveninence and generality factors involved.

For example, you might want the scrip to be used in a systematic over very large numbers of differenc instances. Or, you may want to confirm/validate non-obvious internal details about DOM element settings?

Here's our simple illustration script that uses the main DOM manipulations Illustration of DOM Manipulation Capabilities. This example uses most of the capabilites: value input/output, the ability to find particular DOM elements, and the ability to act on them by modify values DOM attibute level.

Mutation Is Back

Sometimes good ideas never make it, and sometimes they do. Mutation analysis, a notion that goes back to the 1980's (and generated a big controversy in the test community then), appears headed for renewed interest.

Check out the 4th International Workshop on Mutation Analysis, part of the ICST 2009 Conference set for April 2009 in Boulder, Colorado, USA.

For those who don't know what the fuss is about, mutation analysis methods test the quality of a test suite by applying it to versions of the software product under test that have had "mutations" seeded inside; if the suite detects the errors, great; if it doesn't, then you know something is deficient. By the way, "product" here doesn't have to be live code (although it could be) and may include specifications, designs, or other types of objects It's an idea that may be worth looking into.

Welcome to New eValid Users

We're very pleased to welcome the following new eValid users:

Aricent (India) Bisnode Information (Sweden) Defense Contract Management Center Dice.com

Electrabel (Belgium) Loyola University Momentum Advanced Solutions Peterson Holding RegOnline Remindo

University of Southern California University of Pittsburgh Medical Center U.S. Department of Labor WebMD

We appreciate your business!

Using eValid To Study Page Dynamics

As web applications grow in complexity it sometimes becomes increasingly difficult to see what is really going on as the browser interacts with the server. This is particularly true with AJAX applications because sometimes what you see on the page is, to put it simply, not quite what is really there.

This can be particularly challenging when there is near-continuous interaction between the application (running JScript in the browser) and the server, which may be continually updating an iframe on the current page.

Here is a "trick" in use of eValid that will help users see what is going on behind the scenes. You set Detailed Timings ON, and pause eValid in playback, watch the event log for the browser/server communication, and then use your application normally. Here's the detail (including a sample script): Observing Timing and Asynchronous Operations In Web Pages.

eValid Adopted For Loyola University Computer Science Course

eValid has been chosen for use in Loyola University's COMP 370 (Software Quality, Metrics and Testing), being taught by Adjunct Professor Plamen Petrov.

According to Prof. Petrov, the course's graduate and undergraduate students will use eValid to develop a detailed functional test suite for a web based application, and then critique the application in terms of quality, performance, and reliability using a range of eValid features.

Performance of IndexFindElementEx Command

We have done some experiments with the IndexFindElementEx command that compare its performance with the simpler IndexFindElement command. We were looking into this because we noted that some Regular Expression searches seemed to be taking a rather long time.

The performance difference arises because of the difference in searching the DOM dynamically for a simple string match for an atribute, versus doing the same search for a Regular Expression (RegEX) match. The RegEx search turns out to be a great deal more work. Our results appear to indicate that, for a typical complex web page (think of www.cnn.com) the regular expression match process takes about 8-12 times as long as the simple string match. This tends to be the the result of having to do so very much more work.

For example, at typical CNN page has ~2000 DOM elements, so a search of every element for a simple string uses about 2000 "string match" calls (all done in local memory). These matches insist that the string match from the left hand side (from the beginning) of the named property. Because the regular expression search has to start of at each possible character in each DOM value you wind up with quite a large number of searches. Fortunately, the work is all done in memory so the performance is very good!

On the other hand, if you search for a simple string simple string (one without any regular expression characters) using the IndexFindElementEx command, the process needs to examine each DOM element once for each character in the string, to see if it might be a match. As you can guess, this can be a lot fewer searches, and the performance is very quick.

For example, one regular expression search we ran on CNN made 325,000 attempted matches within the DOM for a regular expression, whereas only about 6,100 were needed for a regular (simple) string match. That's ~50 times as much work to the regular expression matching, depending on the lengths of the strings involved. So it is reasonable that when a regular string match on CNN.com takes ~0.2 seconds, the full regular expression match will take ~10.0 seconds. Faster machines will show reduced search times. See DOM Analysis Performance Benchmarks.