- Print
- DarkLight
- PDF
Web Transaction Scout
- Print
- DarkLight
- PDF
The Web Transaction Scout simulates a user's interaction with a SaaS application (or any website). While performing the predefined interactions, the Scout checks if the website is working as expected and can detect errors such as slow loading times.
A test is made up of steps that define what the Scout does on the web page. You can choose from many different types of steps, and use element locators to control where the step is performed.
For example:
- Load the web page
- Step 1: Wait until the username and password fields appear
- Step 2: Enter the username
- Step 3: Enter the password
- Step 4: Click Sign In
- Step 5: Perform some action on the web page
Step Types
This table describes the types of steps you can use to perform different actions on a website.
Step Name | Description | Parameters you need to set |
---|---|---|
Click | Clicks on an element on the webpage. The Scout waits until the element is Visible and enabled on the page before clicking on it. |
|
Press key | Sends a key press to the website. |
|
Assert | Checks whether the text in an element matches the conditions you specify. The Scout waits until the element is visible on the page before checking the text. If the text matches your conditions, then the test continues to the following step. If the text doesn't match, then the test fails. |
|
Insert text | Inserts text in an element. The Scout waits until the element is visible on the page before entering text. |
|
Wait | Waits until an element meets a specific condition before proceeding to the next step. If the selected element does not meet the condition before the timeout duration, then the test fails. |
|
Mouse move | Moves the mouse cursor on the page. This might be needed to "wake-up" an element and make it visible on the screen. | Nothing to configure. |
Mouse hover | Hovers the mouse cursor over an element. The Scout waits until the element Exists on the page before hovering over it. You can use this if you need to hover over a menu to see more options. |
|
Iframe step in | Enters an Iframe on the web page. The Scout waits until the Iframe is available to be entered before performing the step. You might need to perform this step to be able to interact with elements within the iframe. |
|
Iframe step out | Exits out of the currently selected iframe on the web page. If you have previously entered an iframe using the Iframe step in step, then you must perform this step before you can interact with elements outside of the iframe. | Nothing to configure |
Element Locators
For most step types, you need to specify where to perform the interaction using one of the following types of element locators:
- CSS selector
- XPath
We recommend that you use CSS selectors. Web developers often add automation IDs to elements so that they can be easily located using a CSS selector. If you're having trouble testing an internal site, you can ask your web developer to add unique automation IDs.
Some websites dynamically change the names of element classes each time the page loads (for example, div.treeButton__MYZeT
might change to div.treeButton__B4yZ4
when the page refreshes). In these cases, XPath might be the better option to locate the element.
You don't need to be an expert in element locators to use the Web Transaction Scout. Most browsers let you easily copy the CSS selector or XPath for an element, which you can paste into the Scout configuration. The example below shows how to do this with Google Chrome. Other browsers like Edge and Firefox work similarly, but you can refer to your browser's documentation if you are unsure how to do this.
Example: Get an Element Locator Using Google Chrome
- Open Google Chrome and go to a website.
- Right-click on an element and click Inspect to open Chrome DevTools.
Chrome DevTools shows the html DOM Tree and highlights the element you selected. - Right-click on the element in DevTools, select Copy, and choose from the following options:
- Copy selector to get the CSS selector.
- Copy full XPath to get the full XPath.
Create a Web Transaction Scout
- Enter the URL of the website to begin the web transaction. The Scout loads this website at the beginning of each test. After the page is loaded, the Scout performs the steps that you define.
- Enter a Name for the Scout.
- With the Run Every slider, choose how often you want the Scout to perform the test.
- Add a step to define the first interaction the Scout performs on the website after the initial page load.
- Select the type of step to add. See Step Types above to learn how to configure each step.
- Enter all the parameters for your selected step.
- Optionally, click Add name and describe what the step does.
- Select the type of step to add. See Step Types above to learn how to configure each step.
- Repeat step 4 to add more steps. The Scout completes all steps in the order they appear. Here are some tips to help manage your steps.
- Click the up and down arrows to rearrange the order of the steps.
- Click the plus icon to insert a step after the selected step.
- Click the trash icon to delete a step.
- Optionally, add labels to the Scout. Labels are used to help organize and filter Scouts.
- Click Show additional parameters to configure the following:
- SSL Verify. Sets whether to check for a trusted SSL certificate on the website. If you select Yes and the certificate isn't trusted, then the test fails.
- Success Codes. Sets which HTTP status codes the Scout considers a successful response. If the status code of the website is not one of the selected options, then the test fails.
- Screen size. Sets the resolution used when testing the website.
- Overall transaction timeout. Sets the timeout duration for the entire test, including the initial page load and all steps. if this duration is reached before all steps are completed, then the test fails.
- Click Test to test the current Scout configuration. You should test the Scout frequently when you are adding steps to make sure that the step logic and element locators are working correctly.
- Click Save and optionally configure an alert policy before saving the Scout. Learn more about alert policies.
How to Sign in to SaaS Applications
Most SaaS web applications start with a login screen. This Scout can enter a username and password, but does not support multi-factor authentication (MFA). If the application you want to test uses MFA, then there are a few ways to get around this requirement:
- Bypass MFA in your application. In the application you want to test, configure a service account that doesn't require MFA.
- Bypass MFA in your identity provider. In your identity provider, configure a service account that doesn't require MFA. When the Scout attempts to sign in to the application, it is redirected to your identity provider for authentication. The Scout enters the username and password and is returned to the application after authentication.
You might want to bypass MFA only if the sign in attempt comes from a specific IP address. If you are using a Custom Hive, then the IP address comes from the machine where the Custom Hive is installed. To see the IP addresses of Cloud Hives, visit Cloud Locations Used by Scoutbees.
Test Results
When you view a test result, you can see details about the initial page load and all steps performed. You can also see a screenshot taken during each step. Click on a screenshot to enlarge it.
Metrics
The metrics in the table below are collected for each test result. You can create an alert policy based on some of these metrics so that you are notified when something goes wrong.
Metric name | Description |
---|---|
Status | The overall result of an individual test (success/failure). |
Total duration | The time it took to load the page and perform all steps. |
Steps duration | The time it took to perform the steps on the website. This doesn't include the time it took to initially load the page. |
Failure reason | A description of why the test failed. The fail reason generally includes the step number that caused a problem and a description of the problem. |
Page load - connect | The duration of the connection phase of the initial page load. |
Page load - contentful paint | The First Contentful Paint time for the initial page load. At this time, the first content (image or text) from the DOM is visible on the page. |
Page load - DOM interactive | The time until the DOM has been parsed for the initial page load. Generally, at this time the user can begin interacting with the website. |
Page load - domain lookup | The DNS lookup time for the initial page load |
Page load - duration | The total duration of the initial page load. |
Page load - first paint | The time until the first pixels are visible on the screen for the initial page load, including background colors. |
Tips and Troubleshooting
- Use an incognito/private browser when you manually navigate the website to design the test and get element locators. If you have a saved cache on the website, then it might load differently for the Scout.
- Most step types do not have a timeout. For example, a Click step will click on an element when it appears, even if it takes 30 seconds for the element to appear. If you want the test to fail based on the time it takes for an element to for an element to appear, add a Wait step and set the timeout duration.