In this lesson we step you through the editing and testing process for a simple transaction, and we do some basic trouble shooting.

We use the recording from our shopping cart user journey tutorial in this example. If you didn't make your own recording, we have a copy of the script you can use to follow along.

Note: In this lesson, we step into CSS selectors and XPath queries to troubleshoot a simple transaction script. If you're uncomfortable with CSS selectors or Xpath queries, you may want to jump ahead to our next topic, Transaction dashboards and reports.

Manual testing in development mode

Before you start testing, make sure your transaction monitor is in development mode. Development mode is used for editing and testing your monitors. (Learn more about monitor modes.)

  1. Switch to the Main tab on your transaction monitor.
  2. Check the Mode drop-down in the Status section.
  3. Change the mode to Development if anything else is selected.
  4. Save your monitor.

Pro Tip: Hold down the [control] key while you click save to keep the monitor window open after saving.

Start your testing

Since this is a new recording, before you edit anything, it's nice to know that any unforeseen script problems are out of the way. To check for problems, run a quick test. Let the fun begin!

  1. Press the Test now button at the bottom of the page.
  2. Choose a checkpoint from which to run your test in the pop-up window.
  3. Click Test now.

The editor automatically scrolls to the top of the page. The checkpoint adds your monitor to the test queue. Once the test begins, you can watch the test step through your script, and hopefully, you get only successful results.

We weren't so lucky. Steps one (navigate) and two (click on an element) went off without a hitch, but step three failed on the third action.

Screenshot: Test result header

Note: During manual testing (development mode), your test results include waterfall charts and screenshots to help you with debugging. When you move the monitor to staging or production mode, only users with Enterprise accounts can optionally choose to add waterfall reports and screenshots to their steps.

Troubleshooting the script

Scrolling down to the failing step and expanding the action settings, you can see in the Test results section below that the monitor couldn't find the element specified in the CSS selector. This action instructs the checkpoint to change the quantity, but since the monitor can't find the element, the monitor fails.

Screenshot: Manual test result

The full CSS selector reads:

#quantity_5d0164514a05d

So the monitor watches and waits for an element on the page with id="quantity_5d0164514a05d", and when it appears, the monitor sets the element's value to "2." However, the element with id "quantity_5d0164514a05d" never appeared. Why? The selector is looking for a specific ID, but the server dynamically generates the elements ID. Each time the page loads, the element gets a different ID. Don't worry, there are other ways to identify an element other than its ID.

Fixing dynamic ID problems

Looking at the page's source code (below), we see that the element's ID has changed, and the ID is now "quantity_5d51bd8c17323" (your number will be different). The server generates a new ID each time it receives a request for the page. A CSS selector may not be the best option for this element.

<div class="quantity">
        <label class="screen-reader-text" for="quantity_5d51bd8c17323">Quantity</label>
        <input type="number" id="quantity_5d51bd8c17323" class="input-text qty text" step="1" min="1" max="" name="quantity" value="1" title="Qty" size="4" pattern="[0-9]*" inputmode="numeric" aria-labelledby="Suraya Bay T-Shirt quantity">
</div>

To get around the problem of dynamic IDs, we can instead use XPath.

The input element is part of a larger <div> tag with the class set to "quantity" (see code above). Switching the selector to an XPath query, we can change the selector to:

//div[@class='quantity']//input

Instead of looking for the element directly by name, we are looking for the parent element, a <div> that has the static class name "quantity." Once located, the script looks for an input field among the element's child nodes. The script then changes the value attribute for the child input node to "2" (see diagram below).

Chart: HTML tree

When we run the test again, the script finds the element, and changes the value.

However, the test fails again on action 3.4. Action 3.4 is also looking for the input field with the same dynamic ID. Because this action is only an unneeded click action, we can delete the action entirely without affecting the test results.

Note: The Transaction Recorder may pick up redundant or unnecessary clicks. For example, when doing a set action on a text field, the recorder will pick up the click to give the element focus, but the set action doesn't require the click to insert the value. Removing unnecessary clicks shortens the test duration and makes the script more manageable.


Screenshot: Delete a step

Add a new step

Because action 3.6 (action 3.7 before deleting the unneeded check) is a navigation action, let's move it into a new step. 

  1. Click the Add step button (learn more about adding a step).
  2. Drag the new step to position four.
  3. Rename the step to something descriptive (such as "Navigate to view cart").

Move an action to a new step

You now have a new empty step, Step 4. We want to move the last action in Step 3 to Step 4.

You can move actions around in a step, and you can move them between steps by dragging them to the new step.

Click and drag action 3.6 into the new Step 4.

Animation-Drag actions between steps

Add a content check

The new step navigates from the shirt detail page to the shopping cart. To verify that the page loaded correctly, we need to add a content check using stable text that is unique to the page. In this case, we choose the phrase "Update cart."

  1. Click Add action in Step 4.
  2. Click Test document content (This action type checks the entire page for the text).
  3. Leave the first drop-down with the default value "contains" in the action settings, and set the value to "Update cart"
  4. Click Test now to check your work (you should make it to Step 5 before seeing another error).

Further Polishing

In action 5.1, your test fails again. The failure is due to another dynamic ID. The HTML structure for this page element is the same from the dynamic ID issue described above, so you can change to an XPath selector and use the same XPath code you used before, //div[@class='quantity']//input.

Once you've made the above change, your test result should be successful. If not, review the steps above to find your error.

You may want to separate Actions 5.4 and 5.5 into their own step like we did earlier in Step 3 when we broke out the navigation to the cart view (Step 4.)

Next, Switch to Staging mode

Once you have refined and tested your code in Development mode, the next step is to move into Staging mode (Learn more about monitor modes).

  1. Go to the Main tab and change the Mode to "Staging."
  2. Set the monitor to Enabled by checking the box.
  3. Click Save.

You will want to run your new transaction monitor in Staging mode for a couple weeks to test its stability, especially after site updates. Moving the tests to the larger checkpoint network may expose localization problems as well. 

Although the tests in staging mode do not generate alerts, you can view the monitor logs and the Transaction Dashboard to see any errors your monitor may have encountered. Notice the chemistry flask next to your monitor in staging mode (see below).

Screenshot: Monitor log

Clicking the date checks date opens the Check detail report. The Check detail gives you information about the transaction up to and including the error. We get into Dashboards, Check Details, and reports in the next lesson.