The primary methods to improve a Transaction check using Uptime.com are to:
- Improve the data received on an outage
- Validate specific elements are functioning as intended
This FAQ offers an advanced use case that will teach best practices of Wait for Element and various Validators that Uptime.com can use in a Transaction check. The goal of this tutorial is to teach you how to use the Transaction check to identify specific elements and validate a page and its associated infrastructure are rendering properly.
Uptime.com Demo Check | Improve Homepage Form Testing
This demo check will show how commands and validators can provide more specific data to your team:
This check is off to a good start. It verifies our status code and makes sure the Uptime.com tagline renders properly, but the one-second wait time won’t tell us how our site performs.
Tip 1: Wait for Elements, Not seconds
When the next URL or step in a form takes too long to load, it’s tempting during testing to add Wait for 1 Second steps. These steps add unnecessary time to your check, and are not the most accurate way to gauge latency issues. What if the render takes longer than the time you’ve designated?
Instead, use Wait for Element to Exist. Wait for Element to Exist has an individual step timeout of 25 seconds, and it's a much more accurate gauge of performance. The check will move on to its next step once the element is detected. If your check times out, you can investigate this step and its associated moving parts for performance issues.
We’ll use this technique to verify our form is rendering.
We copy the CSS selector for this form:
Then we replace the “Wait for 1 Second” command we used in step three with a “Wait For Element to Exist” command to check for this form:
This tip is most effective when you apply it to elements on your page that load at various times, such as images or analytics code.
Highlight the element’s selector and use a Wait for command to ensure the element loads. You gain performance data about the load time, which contributes to your check’s overall response time and paints a clearer picture of what the user sees when.
Multiple command and validation steps help improve the accuracy of performance monitoring in your Transaction check. With steps properly configured to mimic user actions, you get a clearer picture of the response time of your application.
Use XPath to Locate Text
It is possible to utilize Xpath to locate text within a specific element. Here is an example:
With the above example, it is possible to configure a wait for step that also detects text on the page from a specific element.
Next, we’ll enter a URL and test the form.
Tip 2: Using the Click Step
The Submit form command calls the submit method on a form, and has some specific use cases. It’s almost always best to utilize Click Element instead if you’re filling out a field and clicking a button to move to the next step. Examples include:
- Testing a call to action (as in this example)
- Testing a login form
- Testing a multi-step form
Copy the CSS Selector for the button Start a Free Trial.
Add two new steps that fill the Uptime.com URL into our field and click the button.
Tip 3: Verifying a URL Redirected Properly
To verify a redirect, you need a command and validator to look for information on the page and check the URL. We started this process in the screenshot above.
Step 7 will wait for the next page to render by looking for the element that contains the information we passed along with our form:
Step 8 will check that this element contains “Uptime.com” (the data we passed in our form), and we’ll combine this with our new step 9 to check that our URL is redirecting to its proper place. URL should contain looks for a string of text in your URL, and can check the entire URL if it’s static, or just a partial string as we’ve used in this example:
URL should not contain does the opposite, and is equally useful when you want to be sure that a user is never seeing a particular URL.
A Quick Note on Status Codes
Uptime.com can check for a specific status code, even if that status code would normally indicate failure. There are some use cases where a feature is not publicly available, but administration should expect users who try to access this page to see a specific status code or output. If this example fits your use case, HTTP Status Code Should Be is a handy way to verify the page is rendering as expected.
Tip 4: Logging Into a Website
Logging into a website is easiest to set up in the Transaction Recorder. As opposed to utilizing Basic Auth, logging into an account where the username and password must be entered into a form usually looks like the following:
- Go to URL (With optional validation step to check for status code)
- Fill in Username Element
- Fill in Password Element
- Click the Login button
The above example illustrates this process with validator in step 2 included. After Step 6, your check has logged in and should be able to interact with other elements.
Basic Auth for Login
Basic Auth can be used when you add an Authentication and Settings step as the first step in your check. Provide the user and pass, then login via basic auth with a Go to URL step. We have provided an additional verification that status code is 200 to indicate success:
Improving Your Transaction Check
Using a combination of commands and validators will give us more context for an outage.
We can also confirm none of the elements for a check have been changed and are rendering as intended, especially useful after we’ve made a big change or deployment.
The goal of your Transaction check should be to investigate errors with specific technical details Uptime.com generates as part of its error reporting, including screenshots and performance metrics.