Handling Modal Dialogs in Microsoft Dynamics

The Microsoft Dynamics application providespowerful tools for CRM and ERP in a very powerful and sophisticated online context.

As part of a recent customer support exercise some issues arose in having eValid process some Microsoft Dynamics modal dialogs. Actually, these problem the customer had was being able to successfully dismiss (terminate) a modal that was launched as part of a normal test.

Two routes to dismissing the modal dialog are discussed. One uses an available eValid utility eVclick.exe that sends a left click to a particular spot on the desktop after a fixed time delay. The time delay allows the modal page fully render before being dismissed.

The other route involves using the Dashboard to switch eValid from normal recording mode -- after the modal page appears -- into Desktop Recording mode, where the modal can be dismissed easily.

Our solution is described in detail in Testing Microsoft Dynamics -- Modal Dialog Processing.

• The capability to do functional testing of a mobile app -- Pointers about testing mobile applications. 
• Can eValid be used to test chat? -- Sure can, here's how. 
• A mobile application compared with the desktop equivalent -- Differences highlighted. 
• Put a blank character into a Data Synthesis value string -- Tricks for data synthesis processing. 
• Your BU Estimates -- How many BUs can eValid really run?  

Webinar: Load Testing Mobile Apps

Load Testing Mobile Apps Run 1,000's of Mobile Browser Users Full AJAX Realism Any Mobile Device Identify Performance Bottlenecks

Wednesday, 27 June 2012 2:00 PM Eastern Time / 11:00 AM Pacific Time

QA/Testing/Tuning/Performance projects need to qualify performance of complex AJAX web applications -- within strict budget and time constraints -- to make sure their server-stack setups can meet the load. The traditional methods of ramping up load, based on using HTTP/S simulations or "VUs", don't always work when asynchronous AJAX applications are involved. VU's don't do AJAX. You need a browser. eValid server loading methods offer both quick-to-create, realistic, and fully synchronized AJAX functional tests. Plus you can lift those tests into performance/loading scenarios that can involve 100's or 1,000's or 10,000's of Browser Users ("BUs") per machine. In this webinar you'll learn: how special eValid commands overcome problems with variable-time playback dependency; how to create full-reality AJAX tests quickly; how to adjust tests to be totally self-synchronizing under stressed AJAX conditions; how to incorporate tests in an eValid LoadTest scenario; how to launch 100's or 1,000's or 10,000's of Browser User (BU) instances; and, how to analyze consolidated performance summary data to identify server-stack bottlenecks. This unique approach demonstrates how eValid becomes a genuine force multiplier in your web application performance testing efforts.

Webinar Topic Summary

eValid Architecture and Structure: How eValid functional and performance testing works. Functional Testing: How to make reliable recordings of AJAX applications. Making AJAX Tests "LoadTest Safe": How to augment tests for complete AJAX synchronization. Creating LoadTest Scenarios: How to use the LoadTest scenario editor to organize realistic LoadTest control scripts. Running LoadTests: How to launch single and multiple-instance runs using "cloud computing" resources. Finding Bottlenecks: How to read the LoadTest and other raw data to help spot server-stack issues.

You are cordially invited to attend this free Webinar.

Sample Site Analysis Runs from iPhone

We had some questions asked the other day about whether the eValid approach to emulating a mobile device will let eValid do a site analysis of a web site from the perspective of a mobile device?

So we ran a couple of site analysis runs, aimed at a couple of local transportation systems, and everything worked fine.  Here are the two scans, both done while eValid is dressed as (and behaving like) an iPhone:

   Site Analysis of BART
  
   Site Analysis of SF MUNI

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.

• Typical overhead in CPU percent for a synchronization step -- Very small, slightly dependent on the application, but never interfering too much. 
• Do standard web applications work on mobile devices? -- The answer depends on the website server. 
• On the web or can I test the internal version with eValid -- No problem, and because LAN speeds are high your performance data will be very good! 
• How much variation is there in byte count and download time -- If the page is constant then the byte counts will be too, but the total time is a function of how well the web connection runs. 
• What resources between eValid instances are always shared? -- Details on how to manage the unitary DeskTop and Cache resources.

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.

• Testing uses data storage in the JavaScript working area -- No problem, eValid never touches the JavaScript sandbox 
• Can eValid do a scan of a mobile web application? -- Sure can. Here's how to do it the easy way 
• Can eValid test tablet applications? -- No problem, using eValid's UserAgentString to imitate the tablet. 
• How do you cause a specific DOM element to be highlighted? -- In the PageMap this feedback loop is automatic. 
• Can eValid test multiple mobile devices in the same test? -- Yes it can, by running separate sub-windows with different UserAgentString Settings. 

Is eValid done with JavaScript? Why not?

In our User Forum, Amirr wrote:

Is eValid done with JavaScript? Why not?

No, eValid is NOT implemented with JavaScript, and there are several very good reasons why we chose the eValid implementation the way we did. Here are some of them:

• JavaScript runs in a single thread inside the browser, and the eValid view is that when the JavaScript engine is running the test engine should NEVER interfer with what the browser is doing naturally. To do so would be to violate a fundamential principle: Don't interfere with the process under test -- in this case, with the normal operation of the browser.
• If you are running an AJAX application, then the most common problem in testing is to assure synchronization of playback. Even though eValid records realistic "wait times" during the recording process, we NEVER suggest that relying on wait times for synchronization of AJAX is a reliable approach.
• It's usually the opposite, as we have found out many times. Think of it this way: no matter how well designed your "user wait times" are, there will always be an instance when the wait times you have put into your script are not long enough. The consequences for failure to sync in a test process are very severe: most of the time the test is ruined.
• eValid actually uses a separate, not-in-the-browser process (which actually runs in a thread of the browser process that does not interfere with normal browsing activity) to run commands that "validate and synchronize on DOM property values." There is a family of these commands -- with both positive and negative synchronization modes.
• The key feature of eValid's architecture -- to avoid anything more than the minimum interference with the browser as it does its work, under control of the eValid recording or playback engine -- assures that the results you obtain with eValid are as realistic as possible. We very firmly believe that unnecessary interference with the behavior of the web application you are testing is a very serious "no-no" -- and eValid does not cross that line.
• We understand there are several other web testing solutions that are based on the use of JavaScript and the APIs that obtain within the browser, but we specifically chose NOT to use that available interface for the reasons outlined above. We wanted eValid based web application tests to be accurate, reliable, credible and efficient.