In a global marketing environment in which sales through different company websites are becoming increasingly important, it is necessary for companies to guarantee the performance of their applications and systems to ensure the best customer experience. This is achieved through synthetic probes, which provide accurate, real-time information.
What is a synthetic probe?
Synthetic probes are automated programs to simulate the behavior of real users when interacting with a system or application. These probes can perform specific tasks, such as sending an HTTP request or completing a web form, and then measure the response time and quality of the response received.
What type of probes do you have at your disposal? At Datadope we have two types of probes:
- Synthetic probes: synthetic monitoring with API probes involves the use of automated programs that simulate the interaction of an application with an API, i.e. application programming interface. These synthetic probes send requests to the API and then measure the response time and quality of the response received. In this way, companies can ensure that their applications integrate correctly with other applications and systems, and that they comply with established service level agreements (SLAs).
- Programmatic probes: Synthetic monitoring with browser probes involves the use of automated programs that simulate the behavior of real users when interacting with an application through a web browser. These synthetic probes perform specific actions, such as clicking a button or filling out a form, and then measure the response time and the quality of the response received. In this way, companies can quickly detect any problems in their application across different browsers and devices, and ensure that the user experience is consistent and satisfactory. In the event of an issue, the customer can access a video that allows them to visualize where the probe process has broken down.
In this first entry we will talk about the considerations to create a synthetic probe to simulate as realistically as possible the user experience in a common flow of navigation through the application in question.
Creation of a programmatic probe
The following actions are defined for the creation of a synthetic probe
The objective of this flow is to ensure that the different actions performed by the synthetic probe are as reliable as possible to a real user navigation, in order to be able to deploy the transaction in a productive IOMetrics Synthetix environment to measure the status and timing of the application.
The following needs to be met during the process of creating a programmatic probe are identified:
- Agnostic to possible web page changes.
- Functional grouping of actions to validate different components of the application.
- Validation of the existence and operability of the elements to interact with the application.
To this end, the considerations to be taken into account when generating a programmatic probe are described below:
Recording
For the recording of programmatic probes we can use different recorders available, such as browser extensions or application extensions (VSCode). In Datadope we have our extension that generates the specific format for our IOMetrics Synthetix application:
Refinement: navigation
The objective of our programmatic probe is to simulate the user as realistically as possible and to be able to validate and guarantee that the transaction performed by the user can be carried out satisfactorily and, failing that, to be able to validate that the service exposed to the user works correctly in a reasonable amount of time.
For this purpose, different considerations are listed below in order to improve the design of the transaction itself.
Private navigation
In order to perform the transaction it is important to perform it in an incognito/private browsing window to avoid:
- Saved sessions of previous accesses.
- Saved cookies and to be able to simulate the unique access of a user to our application.
The incognito window will ensure that the cookie banner appears and we can perform actions to validate the banner or other elements that appear. By not having sessions stored in the browser, we can simulate the login or simulate unwanted access to different resources of our application.
Web pages have different loading strategies and during the loading of the same, the elements with which it will interact may appear at certain times of time or not have the functionality because it is added via code.
In order to simulate in a real way the interaction with a user we must use waiting and validation conditions of the different elements of our application with which we are going to interact and that have the desired functionality:
- Wait for the element to exist in our web page.
- Wait for the element to be visible on our web page.
- Waits for the web page to contain a given element.
The use of “manual” waits (e.g. Sleep, Wait, or other commands offered by the framework) should be avoided as much as possible.
Timeouts in waiting and interactions between web pages
In many web pages when the user navigates between different menus or accesses different elements, these make reference to loading new pages or resources where the user must wait for the new view to finish. For each interaction with the different elements it is advisable to indicate the timeout that is considered that the user must wait before leaving the web page, thinking that it is not working or has a problem with its connection.
Locators and element identifiers
The “locators” allow to identify (within the tree of elements that make up a web page in the form of a tree (DOM)) the different HTML elements to interact by accessing their different properties (id, class, text, link, etc.). Most frameworks allow the use of different generic locators that access element properties (id, class, link…), although the most common and generic is the use of xpath.
The same element can be identified by different locators, but it is advisable to use a locator that is agnostic to the different changes that a web page may undergo. To this end, we define the following cases to avoid and where refinement is required:
- Dynamic ID in compilation: the ids of the different elements may vary at compile time of the web page itself.
- Positional elements via xpath
- Style classes not specific to elements
Example: select the Company element
Locator | Recommended | Detail |
|---|---|---|
id=sm-16823485866516055-5 | No | Variable ID, any change and compilation of the web page our synthetic probe will stop working. |
xpath=(.//nav/ul/li/[4]/a) | No | If a new previous section is added to the menu, our synthetic probe will stop working. |
class=elementor-item | No | If the class is used to any other element of the web page and match the desired one, our synthetic probe will stop working. |
xpath=(.//nav/ul/li/a[contains(text(), compa=””]) | Yes | If the class is used to any other element of the web page and match the desired one, our synthetic probe will stop working. |
Credentials and sensitive data
When logging in or inserting sensitive data in the forms of our application, it is important to use the mechanisms offered by the framework to hide and secure our credentials or sensitive data.
To do this it is important to review the synthetic transaction and ensure that the credentials are hidden in our transaction definition and that the credentials are read from a credential manager or other sources.
Refinement: functional grouping
The purpose of a programmatic probe is to validate that a service of our application is available to the user: purchase of an item, validation of inventory, validation of automatic processes…
To complete the probe and validation, the user’s transaction must interact with web elements that in turn make calls to services external to the application itself (call to login service, database, etc.). To be able to narrow down possible problems detected in a navigation and to correct the monitoring of our application, it is important to group the different actions in functional steps and to collect, in the same way as it is done at a global level, the response times and status of each of the functional steps.
Let’s assume the example of an e-commerce where we want to validate that a registered user is able to search for an item in our catalog, access his shopping cart and purchase his product. The following functional steps are defined in order to accomplish the navigation:
1. Home page access
a. URL access
b. Waiting and acceptance of cookies
c. Wait and click on Login button
d. Wait for Login form to load
2. Login
a. Enter user and password
b. Click on Submit
c. Wait for main page to load with user name
3. Catalog access
a. Access the catalog and search for product
b. Select item and add to cart
c. Click on shopping cart
d. Wait for cart to load
4. Purchase product
a. Validate that the product exists in the shopping cart.
b. Validate that the buy button exists
Conclusion
Synthetic probes make it possible to validate the current state of the service from the user’s point of view and, therefore, in terms of value for the specific business. Programmatic probes must simulate in a real way the transaction performed by a user and must be refined as much as possible to be able to detect in time and space the possible errors of our application.
