Transaction Monitoring | Upgrades and Use Cases in 2020
Synthetic monitoring takes care of all of the small interactions on our website that QA can’t catch. If you’re building an application for the web, a transaction check is an integral part of proactive downtime resolution.
What we call transaction monitoring, or a transaction check, is a set of instructions that a probe server follows. Uptime.com collects performance metrics for each step and provides granular data when things go wrong, including HTML output (Raw and DOM), as well as a screenshot. Our check has received a massive upgrade based on your feedback and suggestions.
Today, we’ll look at various scenarios in which our new upgrades would prove effective in testing.
Table of Contents
- What Makes Transaction Monitoring Effective
- Synthetic Monitoring Use Cases
- Use Variables to Exclude Duplicates in Transaction Monitoring
- More Efficient Synthetic Monitoring Setup with Constants
- Elements in Transaction Monitoring
- Transaction Monitoring Using Auth and Settings
- A Brief Snapshot of Transaction Check Upgrades
- Try the Uptime.com Transaction Tool
What Makes Transaction Monitoring Effective
SREs benefit most from verifying a path is accessible on all fronts, as well as how it’s performing under specific conditions. Transaction monitoring offers multiple benefits to QA engineers and SREs:
- Automated monitoring can run with the same level of precision 24/7
- Transaction monitoring involves less human input, which means it scales well as our operations become more complex.
- Synthetic monitors accumulate performance metrics we can use as baseline measurements
- These metrics include DOM render time, better capturing the user experience
- Transactions following specific funnels can alert us when something breaks without the entire URL failing
Transaction checks carry a small setup cost in time, but pay dividends in terms of labor saved and alerts issued. Automating your testing is essential when the focus is on uptime and growth.
Synthetic Monitoring Use Cases
Let’s assume the role of SRE for Edgecom, a cutting edge internet firm that programmatically cuts edges. Edgecom is about to get a shiny new user interface that includes some much-needed upgrades, such as validating a user’s email address as unique.
Today, we’ll look at how variables can be used in our upgraded Transaction Check. Then we’ll test against constants and look at various methods to identify elements. We’ll end with a glimpse at various settings we can use to adjust our testing.
Let’s get to work!
A Quick Note Before we Begin
Before we dive into transaction monitoring as a QA device, I want to quickly point out the importance of RUM. RUM maximizes our data’s usefulness with a baseline measure of actual user performance.
RUM’s primary duties are twofold:
- Issue detailed RUM reports, and a breakdown of load time based on real user data
- Alert us when performance declines
RUM checks alert our team when performance exceeds a predefined value, and we can alter this threshold to suit our use case.
Take the time to create a RUM check now. You will have data before during and after major deployments to compare against your Transaction check reports.
Let’s look at what transaction monitoring can do with variables.
Use Variables to Exclude Duplicates in Transaction Monitoring
Variables allow you to store and re-use elements in subsequent steps, unlocking powerful possibilities for validating elements.
Recall that one of Edgecom’s big changes will exclude users who utilize the same email address twice. We need to test that this form works, without creating false flags, and we need to filter any dummy users from our database.
To solve this challenge, we’ll employ a variable string that will append itself to an email address such as “testuser”. For example, the string 7tu89oul might create testuser789toluu or testuserulout879.
Each time the check runs, this random variable will add a string to your dummy credentials in the sign-up form. You can construct a job on your backend that will automate the detection and removal of the dummy registration for email addresses that begin with testuser.
More Efficient Synthetic Monitoring Setup with Constants
Let’s take this a step further with a Constant. We can test other functionality, such as password changes. A constant is most useful when you have something you want to compare or validate against that rarely changes. Our example will log in, enter the old password on a change form, change passwords successfully, and then change the password back using the constant. Here’s how it works:
First, you need to define the Constant as the user’s password, say TestUser123 as the Constant USERPASS. In subsequent validation steps, you can use $USERPASS$ to fill the password into various fields (such as login or filling in the old password during a password change action).
Use $USERPASS$ to login and ask the check to navigate to your Settings menu. Fill in the field to change the user’s password. For most websites, this involves: entering the old password for validation and then entering a new password before submitting your changes. We’ll use $USERPASS$ to enter our original pass into the old field, then we’ll click the new fields and enter a new user password. Since we need this check to run continuously, we’ll use the constant to change our password back to the old one we’ve defined. Here’s what that looks like with the constant we set above:
Using a Constant will save us some frustration if we need to make some small change to our user’s password. Rather than editing 3 different steps to change USERPASS, we edit only the variable.
Elements in Transaction Monitoring
XPath and CSS selectors are used in various commands and validators. Let’s look at how we can use these selectors to test our shopping cart.
XML Path, or XPath, is useful for addressing a specific node to check whether the value matches your given pattern or expression. This level of precision is not always possible in CSS, making XPath the preferred alternative. Using our selectors, we might construct a test that adds three items to our cart, deletes the second, and purchases what remains.
It’s also possible to use these selectors in variables as well. Select the Element method, and use any of the above to define your selection. Let’s say that Edgecom assigns a unique (to the user) tracking pixel for shopping carts. No matter the session, this pixel will remain the same but it should follow the user if he or she is logged in. When you define an Element as your variable, you can track this pixel throughout a session to make sure it’s persistent:
Transaction Monitoring Using Auth and Settings
Let’s explore the new Auth & Settings command, which adds a great deal of flexibility to the Transaction check tool. If our site rendered best at 1920×1080 or had a mobile component, Auth & Settings is where we’ll configure those parameters.
Here, you can set HTTP basic auth, and control settings including HTTP Headers, Browser Viewport Size, and whether to emulate a Mobile device while checking the site.
There are a ton of possibilities here, so we’ll look at these effects closer.
Basic Auth: The user and password fields allow you to provide credentials for pages behind Basic HTTP Authentication.
For about three months before deployment, Edgecom created a testing website that stakeholders used to navigate the new UI before it was deployed. We used this space to uncover bugs and usability issues, and we secured it with Basic Auth. We can use this setting to login to this test site and ensure the viability of our environment. This way, we can truly set and forget our “dev” environment with technical data when something goes wrong.
HTTP Headers: You can define HTTP Headers to be sent with a request excluding User-Agent, which is disabled. Each HTTP Header you use must be separated by a line break in the Name: value format.
If we went the extra mile in our testing environment and added more complex authorization, we could use this field to provide our check a token it can use to access the testing environment. We could also set language and other useful parameters.
Screen Size: Defines the screen size the check will run, or the device the check emulates. The default is 1024×768. Some websites work better at a specific resolution. This parameter allows you to decide and will affect the screenshots Uptime.com generates.
Mobile: Adds a Mobile flag into the request User-Agent string. When this option is used, the browser also takes into account a page’s `meta viewport` tag and provides touch events support.
We can thoroughly test all of these examples in the mobile version of our website.
A Brief Snapshot of Transaction Check Upgrades
Here are some highlights of what we’ve deployed in this upgrade:
- Upgraded to a recent Chrome version.
- Global timeout alerts include the step and execution time in which the timeout occurred .
- Transaction Checks support the use of XPath in element selectors.
- New Auth and Settings Command
- Transaction Checks display validation errors in the script on Save and Run Test actions.
- New Hover Element and Focus Element commands.
- Full support for embedded IFrames.
- Support for script variables, including constants, random values and date & time.
For a full list of changes, see our status page entry for this upgrade.
In addition to more context for an outage, these improvements upgrade functionality and usability. It’s easier to find the element you need, making your entire check more readable and easier to work with.
Let’s dive into some other notable highlights.
Try the Uptime.com Transaction Tool
We’ve improved the usability of autofill when selecting elements, making this feature more intuitive to the aims of a typical transaction check. Create a command to “Go to URL”, define your URL and then run a Test. Uptime.com will list the button, input, select, textarea and link (a) elements first for easy reference. Just remember, if two elements share the same name Uptime.com will use the first of those elements.
Text fields support RegEx, which allows for complex URL matching and data validation. It’s useful in retrieving database records, locating specific files (or matching output based on strings you define).
We’ve also improved when screenshots are generated, offering more visual aids to assist in diagnosis. No need to leave the page, as each screenshot opens in a new tab. Be sure to use this if your check is experiencing nebulous errors, such as issues related to timeout.
Lastly, this upgrade brings support for elements within iFrames. We hope this improvement will open transaction monitoring to a wider array of sites, and provide a useful tool to keep the internet running.
We’re excited to see what these improvements enable you to accomplish.
Minute-by-minute Uptime checks.
Start your 21-day free trial with no credit card required at Uptime.com.