Best Practices for Synthetic Transactions
If you are just starting with synthetic transactions, here are a few important tips and best practices for you to follow when building out your synthetic transaction library.
Define a Naming Conversion for Transactions
Hunting for the right monitor, especially when you are in a hurry, can get pretty overwhelming. It’s a common problem, especially if you have multiple monitors that target the same service. For example, let’s say you have a ping check that tests availability every minute. Then, you have a monitor that tests the full user workflow. These two are obviously different tools, but you can hardly tell them apart if they target the same production services.
In order to avoid this issue, adopt a naming convention for transactions that’s based on clear and precise guidelines. For example, a convention that’s based on Type - Service - Env, would translate into Ping - Webstore - Production as your synthetic transaction’s name.
Assign Permissions to Protect Sensitive Data
Setting up role-based access (i.e., permissions) to sensitive data is optional, but encouraged. Granting all internal users access to all transactions is not ideal, especially when some scripts can contain or fetch sensitive data. For example, some synthetic monitoring tools do not have the ability to obfuscate credentials, which may alter how you assign role-based access.
The more monitors and users your organization has, the more important it is to use permissions. Role-based access is typically based on user groups. Restrict groups using the least privilege principle to segment access to your synthetic transaction library. That will help you better protect sensitive data and provide a secure experience.
Monitor Third-Party Applications
Many applications rely on external APIs to enhance their user experience. Weather information, music, meetings on a calendar — all of these bits of information require your services to communicate accurately with third-party applications. Submitting synthetic transactions to these external endpoints can help you monitor third-party applications and catch important changes, such as major or minor API version updates affecting request and response structures.
Synthetic transactions also enable you to monitor the performance of your vendors and watch for SLA breaches. Having unbiased historical data on record is essential to confidently holding your vendors accountable to their commitments.
Test New Features
Of course, synthetic monitoring is important at any stage of development. However, it’s exceptionally useful for testing new features before your website or application goes live. Synthetic monitoring is an ideal way to discover possible errors and obstacles that the users might encounter. For example, synthetic transactions can quickly validate that all input fields for a given feature are accepting the right input type’s list of all expected enumerations.
Test From Edge to Edge
As edge computing extends reachability, it becomes increasingly difficult to test all relevant locations without using synthetic monitoring. For example, you may need to check potentially thousands of edge points of presence to validate that a critical update was received. That’s what makes automated monitoring edge-to-edge so critical.
Testing from multiple locations ensures end users have both access and acceptable interaction times with your applications. For example, say that you’ve added a new store location to your app that users can choose when browsing available goods or selecting pickup options. You can use synthetic transactions to test that the newly added store population in the “stores near me” results in Google and that all shopping options are available. At the same time, remember to test regions that represent not just the core of your user base, but also any emerging regions where usage is increasing.
Setting up synthetic transaction monitoring with a scope similar to your reach is the only way to fully validate continual first- or third-party updates.
Set Alerts
Define Performance Thresholds
Define thresholds for the performance and availability metrics of your synthetic transaction so your team can quickly identify problematic trends. Define both globalized (all locations violating) and localized (<n number of locations violating) alerts. You can also set up alerts for consecutive failures and similar trends.
Choose Alerting Pathways
You can get notified of the performance drop in numerous ways. For example, your alerting pathways can utilize SMS, email, push notifications on your mobile device, or even an application such as Slack, OpsGenie, or PagerDuty.
Setup Role-Based Ownership/Urgency Labels
Segmenting alerts by certain groups can also be helpful if the ownership of your applications is divided by different engineering or product teams. For example, a CDN alert can be sent to a dedicated CDN team, while a problem with a social tag may be sent to a campaign manager.
Setting up role-based ownership and urgency labels helps employees understand what they need to pay attention to. Channels that are too noisy may get less attention. Dedicated alerts, however, feel more urgent.
Avoid Test Dependency
Whenever possible, make sure that your synthetic transactions can run independently and in any order. In other words, avoid test dependencies in order to unblock your vision of how the whole application is performing when a given test fails. It also allows you to run many tests at the same time without having to wait for other tests to complete.
Pitfalls for Synthetic Transaction Testing
This section is dedicated to some of the challenges and pitfalls you might face when managing synthetic transaction testing.
Captchas
Many websites use Captchas, which are designed to prevent the type of automated (bot) monitoring that is at the core of synthetic transaction monitoring. This makes relying on synthetic transactions for performance data more difficult. You can get around Captchas by either disabling them in your test environment or adding a hook to allow tests to bypass them.
Two-Factor Authentication
Two-factor authentication (2FA) works by creating a temporary, one-time password using certain mobile apps, SMS, or email. It is difficult to factor into automated testing.
You can disable 2FA in a test environment, or disable it for certain users, or disable 2FA for users who log in from certain locations (via IP addresses). However, considering the importance of data security, it’s highly recommended that you select a synthetic monitoring tool that has the ability to incorporate 2FA as part of your testing selection criteria.
Social Logins
We don’t recommend logging into popular websites such as Facebook and Gmail using tools like Selenium’s WebDriver API. Not only is it slow, but you can also get your account banned.
It’s much better to use APIs that email providers offer, or the Developer Tools Service in the case of Facebook logins. It might seem like extra work to become familiar with the APIs instead of logging in via the UI, but in return, you will get more speed and reliability.
Key Functionalities of Synthetic Transaction (Monitoring) Tools
Now that we’ve gone over the do’s and dont’s of synthetic transactions, let’s review what features a good synthetic transaction monitoring tool should have.
- Support for multiple types of logins: Enables you to login using SSO, Citrix, XenDesktop, AWS Workspaces, etc.
- Simulation of different protocols: Enables you to leverage REST, JSON, YAML, HTTPS (web), SMTP (email), ICA (Citrix), SQL (database) for various situations.
- Record and replay: Enables you to record a user-driven transaction and replay it instead of writing a script. Revision to certain classes, without re-recording the whole transaction, should also be possible.
- Smart element locator: Enables you to find UI elements as the design changes over time.
- Conditions: Enables you to direct transactions to wait for the completion of another step or even loop the transaction a certain number of times.
- Support for various types of variables: Enables you to reuse tests dynamically based on data like the location.
- Reusable steps: Enables you to reuse and reassemble simulation components to build new tests.
- Continuous integration: Enables you to run scripts triggered by events in your DevOps continuous delivery processes.
- Assertion and Validation: Enables you to validate a boolean expression to be true or false before proceeding. The assertion validation can be a 200 HTTP response, a JSON payload, or in a form of an image or text on the website. You also need a Safe Harbour feature to make sure that content complies with privacy laws in a specific country. In addition, assertions can be used in the absence of certain elements, such as an out-of-stock item on e-commerce websites and stores.
- Step-by-step measurement and completion events: Enables you to record a separate measurement for each step. The completion event, for example, lets the synthetic monitoring node know when the monitoring is complete.
- Step-by-step analytics: Enables you to evaluate the performance and availability data for both an entire transaction and its individual steps.
- Payload execution time extraction: Enables you to execute and extract custom payloads, and separate them from your total transaction times.
- Support for Selenium: Enables you to quickly compose tests referencing a list of functions and examples that populate the IDE.
- Data grouping: Enables you to compartmentalize data subsets into themed measurement units (e.g., tied to a CDN or to infrastructure).
