Our Selenium Synthetic Monitoring Stack
We maintain a highly optimised browser automation stack in order to provide the most stable environment for our customers to run their Selenium scripts in. Our goal is to deliver the best user experience for writing and maintaining a synthetic script and configuring the browser environments it runs in.
The synthetic monitor data we produce is used for simulating website processes such as form-based authentication, eCommerce transactions, and regulatory checks. We also help to identify performance issues in page load time and the response time of individual user actions. This is a tall ask, and our testing tool hasn’t always been as feature-rich as it is today.
Unlike our competitors, all our synthetic monitor scripts are available for our clients to view and update themselves, via an intuitive, accessible wizard. We pride ourselves on offering a low-code alternative that is accessible to anyone and doesn’t require any experience with programming languages. However, this doesn’t mean that our synthetic transaction stack running the tests under the hood is substandard. Our stack is built using the industry-standard automation testing framework; Selenium and Selenium WebDriver, an actual browser; Google Chrome, and on reliable, Amazon Web Services cloud infrastructure.
Thankfully, all of this has changed. We now test our customer’s complex user journeys using an actual browser – Google Chrome – in order to create a lab environment that closely mimics their users. We use Chrome because not only is it the most popular browser but it gives us the most access to its internal APIs, which means we can extract better timing and logging data than with other browsers.
Chrome is orchestrated by Selenium via Chromedriver. Our scripting layer interacts with this via the Selenium WebDriver API – this is what gives our clients the ability to script their own journeys made up of Selenium commands, but with very little previous experience or expertise.
Our HARs are no longer extracted manually from the browser and instead are generated using a localised proxy server that is designed for this very purpose. This guarantees accuracy and completeness in our network interaction analysis during a journey test.
RapidSpike’s low-code scripts are made up of Steps that contain Actions. Steps is a tool available to split “Actions” by the target website pages. This helps with metric segmentation, debugging and script maintenance. Scripting Actions translate to WebDriver API commands in our scripting layer, which enables us to upgrade Actions behind the scenes, without requiring updates to all our client’s scripts to take advantage of new capabilities.
This stack is built into our injectors that run on the most optimised instance types for our workloads in AWS cloud infrastructure. We take care of all of this so you don’t have to. Our test injectors only ever run one test at a time. We do this to ensure there is no noise produced from running multiple tests simultaneously that may affect each test success or performance output. Finally, all tests are conducted in completely fresh browser sessions, in containers that have been restarted and cleaned between tests.
All of this contributes to our test framework being industry leading, battle-hardened and guaranteed to produce consistent results, from an accessible, low-code scripting engine.