1. Support
  2. Uptrends Academy
  3. Course: Web application monitoring / transaction monitoring
  4. Testing and editing your transaction scripts

Testing and editing your transaction scripts

We’re changing our user interface. Some info may not yet be up to date. Please check From classic to new UI.

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

We use examples below that come from an earlier exercise: Transaction Recorder shopping cart tutorial. If you haven’t already completed this exercise, you may want to do so now, or you can cut and paste the script into the step editor.

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 and you have chosen to have Uptrends Support stabilize and test your scripts, you may want to jump ahead to our next topic, Transaction dashboards and reports.

Manual testing in development mode

You have three options for your monitors, development, staging, and production mode. Testing in development mode is the most important thing you can do before moving a transaction script to staging or production mode (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 using Test now

Whether you’re starting with a script straight from the Transaction Recorder, making changes to your script, or troubleshooting problems on a script in production, you’ll use the Test now button. To check for problems, run a quick test, and 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.
Important: A successful test in development mode is not an indicator of a stabilized transaction script. Follow all of the testing recommendations before moving a transaction script to production.

After you begin the test, the editor automatically scrolls to the top of the page, and the checkpoint adds your monitor to the test queue. Once the test starts, you can watch the test as the checkpoint steps through your script. If your script finishes with a successful test, well, that is really great, but a successful result doesn’t mean you’re done testing.

If you’re using the sample script, you’ll notice that Steps one (navigate) and two (click on an element) went off without a hitch, but step three failed on the third action.

Pro Tip:
During manual testing using the Test now button, your test results include waterfall charts and screenshots to help you with debugging. Click the button Test results available to view screenshots and waterfall reports. When you move the monitor to staging or production mode, only users with Business or Enterprise accounts can optionally choose to add waterfall reports and screenshots to their steps.

Troubleshooting the script

A transaction may fail for many reasons while in development mode such as missing content or selector choice for elements, tabs, and frames. We also have more examples in our Knowledge Base.

Element not found: Handling dynamic IDs

In the example script test, you can see in the Test results section below that the monitor couldn’t find the element specified in the CSS selector. The action tells the checkpoint to change the quantity, but since the monitor can’t find the element, the action fails.

The full CSS selector reads:


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 element’s ID. Each time the page loads, the server gives the element a different ID. Don’t worry; there are other ways to identify an element other than its ID.

Fixing dynamic ID problems

To get around the problem caused by dynamic IDs, you need a different selector. Click on the button in the selector indicator box to view a selection of other possible selectors (see below).

In this case, you’ll notice that several of the selectors use the dynamically created value, so you can eliminate those selectors right away (see below). Two other options don’t include the dynamic ID: name and xpath:idRelative. The recorder automatically orders the selectors based on its opinion of what selectors will work best. In this case, the second recommendation, “name” may work better for identifying the element. The name value is an element attribute, and if unique to the page, the selector is probably your best choice.

As it turns out, the xpath:idRelative option also works in this case. Uptrends gave us two valid choices that work great in development mode, but you won’t know for sure that they work well until you move the script to staging mode. However, you’ve got more things to do before moving your script to staging or production mode.

Element not found due to lack of user interaction

Just like dynamic IDs, dynamic content that requires user interaction before an element is visible can also cause problems. Finding them may be tricky, but the place to start is to really consider the details of the user interactions.

Add hover actions

Some page elements do not load or become visible until the user hovers the cursor over the element. For example, if a user needs to hover over a menu to make the submenus visible and accessible, the script needs to perform the hover action too. However, the Transaction Recorder can’t capture hover events, and if an element is not visible on the page, the script can’t interact with it. You’ll need to add a hover action before the dependent interaction. Learn more about hover actions.

Error due to time out

When the script is running, it continues to look and waits for elements to load. The default wait time is 30 seconds, and 30 seconds is typically plenty of time. However, if the 30 seconds is not enough time, you may have reason to add additional wait times to an action. For more information on using wait conditions, see our Knowledge Base article Using Wait Conditions.

Causes for timing issues

  • Element is not yet interactable: extend the wait time.
  • Transaction timeout: A transaction has a maximum run time. Ask support to look at your script to help you find the issue.

Important: We can’t stress how important content checks are to the success of your transaction monitoring. Please add content checks after every navigation or content refresh. Use them before each interaction. Content checks are free, and they make your monitoring more robust (learn more).

Errors due to missing click actions

Missing clicks before set interactions may cause unexpected errors, avoid errors by always including a click action with each set interaction.

Don’t use the enter key: When recording your transaction, you may have used the [enter] key rather than clicking a submit button. For example, when using a search feature, the natural action is to hit enter rather than the search button. The recorder can’t pick up the use of the Enter key. When you find you’ve done that during your recording, add the click action. If there is no button option, contact support to help you figure out a solution.

Missed clicks: Don’t remove the clicks before entering values into fields, click events trigger value masks and other events within the browser. In some cases adding two clicks before entering a value is necessary.

Learn more about click interactions.

Script testing checklist

Before moving your transaction monitor to staging, there are several things you must check first.

  • Put in content checks. Add a content check after every page transition to verify that the right page loaded with the correct content.
  • Check the screenshots and waterfalls. While in development mode, each step generates a screenshot of the browser window and waterfall chart, check the waterfalls and screenshots to verify page flow, content, and accuracy of products/items.
  • Read the transaction caveats. Make sure your monitoring will not have negative consequences for your business.
  • Add click actions before entering values in text boxes.

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 of weeks to test its stability, especially after site updates. Moving the tests to the more extensive 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).

Clicking the 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.

All articles in this category

By using the Uptrends website, you consent to the use of cookies in accordance with our Cookie Policy.