Conversation With a Test Manager (Part III)

In Part I and Part II we related how eValid dealt with concerns about eValid technology and about reliance on the record/play paragigm. Here we finish up looking at issues of operational complexity and overall field costs.

• "Effective Use of eValid Will Be Obscured By The Complexity Of The Scripting..."
  Actually, it's the opposite. eValid's approach is to AVOID scripting as much as possible and to resort to manual script modifications only as a last resort. It's cheaper that way.

  We have found that 99.99% of the time the "from life" recorded script is adequate as it stands, mainly because Adaptive Playback (defaulted ON) softens the "brittle nature" of the script/application correspondence.

  In practice, users record scripts from life and then modify and/or augment the generated script by manually adding commands (e.g. AJAX synchronizations) as required. You don't have to remember any script syntax -- eValid does that for you. This process is enormously more efficient that hand-coding tests from first principles -- which eValid users normally never need to do.

  The Testing the GWT "Kitchen Sink" example scripts show some of these modifications, e.g. when extra validation steps were added to confirm that the playback arrived at the correct end state.

  An even better example of this is a sample test of Gmail, which shows a number of hand-modified advanced-usages of AJAX synchronization command is our Testing Google Gmail with Index/Motion Commands.

• "But, Hey, That's Great But I'm Really Concerned About Productivity Costs..."
  eValid is first and foremost a productivity tool. For web applications eValid's automated script recording, augmented with a few hand modification of scripts based on some knowledge of the available "extra" commands, and in a context that includes AdaptivePlayback, easily trumps every other approach in terms of productivity.

  The famous testing notion "...if it ain't broke, you're not trying hard enough!" is only going to be effective if you can try things out in sufficient quantity AND quality. Think functional coverage here. A script that costs $5,000 to develop and that tests one feature brilliantly is never going to have the quality enhancement effect of 100 scripts that cost $50 each to develop, because these 100 tests may cover 100 different functions. The more different things you test the better off you are.

We hope you enjoyed our interview!