In this example we’re going to set up end-user experience monitoring for squarespace.com. Squarespace is just one in a category website building tools that enables designers to create and edit pages from inside their browser.
For our example script, we’ll simulate how a user would navigate the application in order to change the announcement bar on the website shown below. Since these kinds of tasks are performed via a browser-based UI, we expect the script will include a login, additional page loads, css animations, and forms; since the website is generated by the squarespace application, we’ll also have a chance to target html elements with unpredictable attribute values.
- Start recording
- Save and play back
- Form fields
- Changing selectors
- Set start point
- Step thru and playback speed
- Add comments
- Copy source to AppView
- Variables and milestones
- Element not found
- Successful preview
The application is squarespace and so the target url will be http://squarespace.com. We enter the url at the top of the plug-in, toggle over to the table view, and then click record.
Verify that you’re recording! It’s hard to tell just by looking at the record button whether or not it’s recording. Hover over the button to reveal a tooltip.
Switching over to Firefox, we enter the same url in the address bar and execute our first action, which is logging in.
Let’s check the plug-in to make sure our actions were captured by the plug-in. We’re expecting two commands: in every script, the first command is always
open; the remaining commands are case-specific. In our example, we’re looking for a
click vs. clickAndWait: Many selenium commands come with an
AndWait variant, which instructs selenium to execute the command and then wait for a new page to load.
Save and play back
Now that we have some content, let’s save our work using ctrl/cmd+s, stop recording, and then play back the script using the ‘play current test case’ button. When you play it back you’ll be able to watch each step execute in Firefox.
We can see in the logs at the bottom of the plug-in that the script completed successfully, so can confidently continue recording.
Let’s pickup where we left off by logging in. There are two fields, email and password. Notice that the plug-in automatically identified the input boxes by the id attribute and recorded the values we entered.
Re-start recording: Click on the table row of the last command in your script before you re-start recording so that subsequent commands are recorded in the right order.
Re-arranging commands: You can cut, paste, copy, delete, and undo commands in the table view using hotkeys or the ctrl+click menu.
Playing backing after logging in gives us our first opportunity to troubleshoot. You can see that the script stopped at the 3rd command. Why? The log says ‘element not found’. Typically platforms like Squarespace, Wix, and Drupal dynamically generate element id’s; the tip off is the long string of meaningless numbers. We need to base our script on attribute values that will persist across multiple executions.
The plug-in makes it easy to fix this type of error. Select the row that threw the error and notice that the target field has a drop-down. At the time the command was recorded, the plug-in captured several alternative ways of identifying the target element. We’ll choose xpath position because it’s the only option that doesn’t rely on the problematic id attribute.
Set start point
After changing out all of the selectors that are based on the id attribute, we can run the script again. Because we know that the first two commands work, we can save some time by testing only the log in portion. This can be done by setting a playback start point.
- In the plug-in, click on the row you want to start on and press ‘s’.
- In Firefox, navigate to the page where the start point will be executed.
- Click ‘play current test case’.
We expect a successful playback since we changed out the problematic selectors, but instead we get an error.
On a second attempt, we get a different error! What’s going on?
Step thru and playback speed
To isolate issues, it’s helpful to be able to execute commands one at a time. You can do this in the plug-in as follows:
- In Firefox, navigate to the page on which you want to execute a command.
- In the plug-in, click the command row and press ‘x’.
Stepping through each command proves that the plug-in can successfully execute the commands, and the login credentials were correct. Something else must be wrong. Let’s try slowing the script down, simply because the speed control is staring us in the face.
Slowing down worked. We can continue recording, but playback speed something we should watch out for because AppView doesn’t have a control for this.
Playback speed: AppView doesn’t have a control for playback speed. You may have to troubleshoot further once the script is in AppView.
Getting to the announcement bar config page is matter of a few more clicks. Straightforward enough. But before we transfer the script over to AppView, there is one clean up operation that we find helpful, which is to insert comments. Script comments are not used by AppView, but they do make the script easier to read, especially when using several xpath selectors in a row. To insert a comment, ctrl+click the row above which the comment should be inserted and select ‘insert new comment’.
Copy source to AppView
We’re done recording, so now we can toggle over to the source tab in the plug-in. We select all of the xml content and paste it into the AppView source tab.
Variables and milestones
Toggling over to the table view in AppView, we see pretty much what we saw in the plug-in. But we don’t want our password displayed in clear text so we have to replace it with a variable. We define it as ‘pwd’ because that’s the variable name that AppView recognizes. Then we can replace our password in the table view with
After replacing our variables, we’ll clean up our milestones. We’ll follow the same format as the default but use a more meaningful description. So instead of ‘Milestone 2: clickAndWait’, we can write ‘Milestone 2: Login’.
Save your config! After importing your script and cleaning up, scroll down to the bottom of the user actions config page and click ‘save’.
Element not found
Time to preview. On our first attempt, we get an error on the Milestone 2.
Fortunately, we’ve already been through a similar ‘element not found’ error above. We’ll go back to the plug-in and find an alternate selector. The plug-in has a
//a[contains(text(),'Log In')] selector. It doesn’t look like it relies any dynamic attributes, so it should work.
On our second preview attempt, there’s a problem with Milestone 3.
The error says something about an overlay receiving the click. Because we’re familiar with the site, we know that there are a lot of animations during page transition. We also know from previous troubleshooting that the script does better when played back at a slower speed. Let’s see what happens when we change the 5th command from
Notice how changing
clickAndWait created a new milestone automatically. This is because the
AndWait signals to AppView that a page transition is involved. While this might work, it’s not what we want. This command represents clicking the login button, and so we want it to be part of the login milestone. Instead, let’s try pausing for 1 second.
On our third preview attempt, we get the same error as the last preview, but now we’re farther down the script. This time there’s a problem with Milestone 4.
This milestone has three commands. Generally when a milestone has more than one command, the error could be caused by any one of them. In our case, the first command is already an
AndWait. The third command in the milestone is the last in the script, so it’s probably not the culprit. Let’s change the second command to an
AndWait and see what happens. Since it represents a page transition we’re okay with declaring it as a separate milestone.
Success! The script completes, and we can verify that we end up on the right page by scrolling to the last screenshot in the preview. From here we might try to reduce the length of the pause to see the minimum we can get away with. Alternatively we can just increase our Apdex thresholds so we don’t roll into tolerating/frustrated territory just because of an inflated pause.