This is the first post in a series on how to get the most out of Web Performance Monitor. WPM is a powerful tool with some very useful features that might not be so obvious.


THE PERILS OF JAVASCRIPT

When you are making a recording in WPM, you may notice that everything was recorded without issue, but when played back the transaction always fails. Why is that? Most often the culprit is a JavaScript action which did not fire when played back. Everything works just fine in your browser, but for some reason the transaction always fails in the WPM player.


Imagine the simple case of a menu dropdown which is effectively a hidden element on a website. There are web pages which load such menus dynamically, so it’s impossible to locate that element on the page before you trigger the appropriate JavaScript handler. Another example is a dynamically generated ID for an HTML element like menu items. It’s always different, making it impossible to reference.


How can we go about recording edge cases like these in Web Performance Monitor? Let’s take a look.


One way to address this problem is to use your keyboard for navigation instead of the mouse. Try using the tab or arrow keys to move around the page and use the space bar to select and de-select checkboxes. This way, instead of WPM referencing static element IDs, you can navigate to the correct element with a series of key strokes.


In the case where you are testing the general availability of the website or application versus specific features or links on a page, consider using alternative navigation paths to reach the page you want. It is often the case that certain pages are navigable from multiple points on the website. Use the simplest way to reach a page or do an action, especially if it’s not necessary to test a navigation option that requires JavaScript.


On the following screenshot you can see examples of three different links to the Solution Finder on www.solarwinds.com. There are two static links directly on the web page (marked in yellow) and one through a dynamic JavaScript menu (marked in blue).


Pasted_Image_28.3.2013_10_55-2.png


Another option is to leverage native keyboard commands supported by some applications. For example, Gmail supports keyboards shortcuts like “c” to compose a new message, “r” to reply to a message or “e” to archive it. WPM normally records only keyboard actions related to forms and navigation around forms, so you might need to enable XY mode to record all of your keyboard actions and thus these keyboards commands. We will talk more about XY mode later.


Another option which might make your life easier is a neat trick with using “ctrl-shift” during your recording. If you hold these keys during your recording, WPM will record extra steps like mouse-over or mouse-down, helping you to record the display and subsequent click of menu items. WPM doesn’t normally record all possible events on the webpage. This is to prevent unnecessarily long recordings in most cases; however, sometimes you’ll actually want all steps recorded and using this keyboard combination allows for that.


On the screenshot below you can see actions that are recorded using ctrl-shift while randomly wandering around the main Google page with the cursor.


Pasted_Image_28.3.2013_13_32.png


If all else fails, use XY mode. XY mode simulates mouse actions at the operating system level (as mentioned another characteristic of XY mode is, that it also records all keyboard actions). Because of this, there is no feedback to WPM that the mouse action actually worked. Therefore, always combine XY mode with some other validation (textual or image validation) on the page. XY mode will send mouse click actions to the defined absolute coordinates and thus helps you if for whatever reason JavaScript actions are not firing. Because XY mode uses absolute coordinates and webpages are constantly changing, elements on the page can often move so it's safer to avoid XY mode until you’ve exhausted other options. Your transactions will be more stable and easier to maintain.


KEEP IT CLEAN

WPM records all of the actions you make in the browser, intentional or not. In addition, user navigation on the webpage isn’t mechanically precise. Users can wander around the page with a cursor, or unintentionally point to various objects, all of which can trigger actions that you may not want to be recorded by WPM. All of that noise is later played back every time WPM interacts with the application.


This can of course cause prolonged response times. These types of recordings are also more prone to failures. In addition, webpages change over time, making it harder to maintain your recordings.


On the next screenshot you can see that I only moved the cursor over a menu dropdown on www.solarwinds.com and it generated several other mouse over events.


Pasted_Image_28.3.2013_13_35-2.png

 

For these reason it is best to keep your transactions minimalistic and clean. Use only actions which are necessary to verify the application is up and that the monitored functionality works. To keep your recording clean, either re-record it a few times until you find an ideal set of user actions, or manually remove and modify any recorded steps that need it.


In the next post we will look at how to master using WPM remote players and share some more tips and tricks on how to create more stable recordings.