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.
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:
Next, we’ll enter a URL and test the form.
Tip 2: Click vs Submit for Forms
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 Redirect
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.
Improving Your Transaction Check
These extra validators will give us more context for an outage. Here are some examples of outages this check will catch:
- Our homepage is giving us a status code other than 200
- Our tagline has been changed (we can confirm IT is aware)
- Our form is properly passing data
- Our redirect is working properly
We can also confirm none of the other elements in our other steps 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.