1qvd wrote:I've heard about your "record then script" methodology and why it's better. Can you expand?
The goal of any good engineering process is spend the least amount of time getting the greatest amount of benefit.
In the eValid context, there are two competing factors that have to be considered.
First, that record/play engines have a reputation for producing brittle tests -- tests that break quickly. Obviously brittle tests defeat the advantage of the simplicity of the record/play process. eValid overcomes this objection with the automatic recovery processes implemented in the adaptive playback feature. Tests that are run on page that has changed do NOT fail in eValid so long as the changes are within certain pre-determined ranges (based on common sense and practical experience).
Second, in most systems in the "software test tools category" the script is expressed in some kind of programming language. eValid test scripts are expressed in a simple, text-oriented command language which is easy to understand, and easy to edit. This means that even when a test regresses (the application has changed so much that adaptive playback no longer counteracts the change), the the work of updating the script is minimal.
The sum of these two effects is to permit an eValid user to create the largest number of tests, with the greatest durability, in the least time, and without needing access to specialized programming skills. Which is why we think eValid is better.
eValid Solution Architecture Team
by 1qvd » Tue Jan 25, 2011 4:06 pm