|
eValid -- Automated Web Quality Solution
Browser-Based, Client-Side, Functional Testing & Validation,
Load & Performance Tuning, Page Timing, Website Analysis,
and Rich Internet Application Monitoring.
|
|
eValid -- Testing SalesForce -- Example #1
eValid Home
Summary
The
www.SalesForce.com application,
which represents one of the earliest "Software As A Service (SAAS)" offerings,
is well known for its very sophisticated use of JavaScript.
Because of its internal complexity,
and also in part because the application is under constant modification and
update,
successful
functional testing of the SalesForce application
has always been somewhat challenging.
Movies of the successful application of eValid to SalesForce are available
here.
Test Plan
Below is the testplan for Example #1.
(The SalesForce account used is a temporary one;
it may not be available in the future.)
The idea of the test is to log into the account, create a new unique customer,
add some data to that customer's record,
confirm that the new customer data is present, and then log off.
- Step #1: Go to https://login.salesforce.com's basic login page...
- Step #2: Input your UserName and Password...
- Step #3: Await Authentication and navigation to Getting Started...
- Step #4: Click on the Accounts tab to go to Accounts Home area...
- Step #5: Click on the New button to go to Account Edit New Account...
- Step #6: Input and Navigate some input fields and Save...
- Step #7: The named New Account is created and displayed...
- Step #8: Click to add New Contact record information..
- Step #9: Input and Navigate Contact Edit area...
- Step #10: Click Save to create the record...
- Step #11: The new contact record is created and displayed...
- Step #12: A Reminder option is triggered in a Popup Sub-Window...
- Step #13: Clicking the Yes button closes the Popup Sub-Window...
- Step #14: An option to Send a Stay-in-Touch Request appears...
- Step #15: End the scenario by Clicking on Logout...
- Step #16: Your session logged out successfully...
- Step #17: View Playback Data results...
Developing the Test Script
The
SalesForce Example 1 Test Script
illustrates eValid's success with this complex example.
This example was developed using certain practical guidelines,
gained by our real-world experience with the SalesForce application itself.
We have seen that the "current instance" of the SalesForce JavaScript can change,
with behaviors that are identical to a prior version,
but with internal changes that cause a variety
of test playback problems.
In other words, while nothing in the application appears to have
regressed, sufficiently many changes occur so that even eValid's
Adaptive Playback feature can't overcome them.
Accordingly, we made our recording and post-processed the script
according to the
AJAX Recording Protocol.
Here is a summary of the changes made after the "from life" recording was made:
-
Corrected Navigations:
The most common regression experienced is that FollowLink
commands change outside Adaptive Playback's ability to compensate.
The most-reliable fix for this is to convert the problematic FollowLink's
to pure-structural DOM-based passages.
-
Adjusted NAV/NO_NAV Tags:
"From Life" recordings often problems with NAV tags.
Depending on how the UI control is handled by the underlying JavaScript
eValid may record an unnecessary NAV tag,
or eValid may fail to record a required NO_NAV tag.
Because navigation events are dependent on how the JavaScript is written
-- over which eValid has no control --
there is
no way to reliably know which is the correction option.
For technical details see the
eValid
NAV and NO_NAV Explanation.
-
Assured JavaScript Settling Time:
We added some constant Delay commands to make sure
that JavaScript initialization and/or update is complete.
-
Disabled ElementFocus Commands:
If the contents of a recorded element focus change in the
application, playback will cause Adaptive Playback to search
the entire JavaScript file, which will take so long and consume
so much resources that you will get to a "non-responding" state.
It is usually safe to disable such passages.
Final Script and Playback Variations
The completed
Example 1 Test Script
incorporates all of the changes needed for this particular test plan,
after first making a "from life" recording using the
AJAX Recording Protocol.
You can look at a sequence of
Screen Images
taken after each step in the test plan.
There are YouTube movies
of the automated test playback, with two variations (click below).
In both cases you'll see eValid launched, opening and positioning of the Script Window
and opening and positioning of the EventLog Window.
After test playback starts by clicking the Play Icon,
you'll see:
(i) the script steps marching through highlighted in the right-hand window;
(ii) the activity in the EventLog in the bottom window; and,
(iii) the activity in the evalid browser as it drives
the SalesForce application in the upper left.
- Standard Speed Playback (Left)
The recording from life that you see played back in the YouTube movie
(on the left)
is running in "real time," i.e. Standard Speed.
Every delay made during the recording is faithfully
reproduced.
The total script playback time is 310.1 seconds;
the duty cycle
of that playback is 20%, meaning that 80% of that time is spent
waiting (expending "think time").
- Full Speed Playback (Right)
By adjusting the Playback Wait Time Multiplier to 0
the playback runs at a 95% duty cycle,
with a total playback time of 59.8 seconds.
There's no unnecessary waiting by the playback engine;
all of the waiting time is for the SalesForce application and website to respond,
and for the test to confirm synchronization.
Viewer warning: things go by very quickly in the Full Speed Playback
Standard Speed Playback
|
|
Full Speed Playback
|
Compatibility Note
SalesForce has recently enhanced the security of their website, and the above script
may not work "out of the box."
You may need to create your own account and make appropriate changes in the script.
Alternatively,
you may use your own SalesForce account and start the eValid playback at the
section AFTER the login section (i.e. run the script already logged in).