Six years on a distributed load testing platform

Six years of development

This partnership began when we helped upgrade legacy Ember to the Octane edition. We migrated components incrementally from outdated patterns to modern Ember Octane architecture, ensuring zero downtime throughout the transition. What began as an Ember.js upgrade evolved into full-stack platform development.

Octane was not a cosmetic change. It replaced the object model, the component lifecycle and the reactivity system at once, which is why so many Ember applications stalled on older versions rather than move. Doing it incrementally, on a platform that enterprise customers were actively load testing against, meant every migrated component had to behave identically to the one it replaced.

AI-assisted testing

The platform’s newest capability: users ask AI to generate test scenarios, run scripts, and summarize results in plain language. We designed and built the Ember.js interface for these AI features, from conversational scenario generation to AI-written run summaries, integrated into the dashboard our team has been evolving for six years.

The interface problem here is harder than it sounds. A load test produces enormous volumes of timing data, and an AI summary is only useful if the reader can get from the summary back to the underlying run. The dashboard had to hold both, the generated narrative and the raw numbers behind it, without either one burying the other.

Testing agents

We built and maintain the Node.js test runner agents that power Testable’s distributed testing. These agents integrate with Playwright, Puppeteer and Postman, allowing users to run their existing test scripts at scale without modifications. The agents coordinate with the Scala backend to distribute load across cloud regions.

Running somebody else’s unmodified test script across a hundred regions means the agent has to be tolerant of everything the script might do, while still reporting timing data the backend can aggregate. Compatibility with the tools customers already use is the product, so the agents follow those tools rather than the other way round.

Headless browser video recording

One of the most technically challenging features we delivered: recording video from headless Chrome instances running inside virtual servers with no GUI. Users can now watch exactly what happened during their test runs, even when browsers spawn across distributed infrastructure. This required deep integration with the test runner architecture.

There is no screen to capture in a headless environment, and no window server to ask. The recording has to be assembled from the browser’s own rendering pipeline, then shipped off the machine and stitched back to the run it belongs to, for hundreds of browsers that may exist for less than a minute each.

Admin panel

We have built significant admin panel functionality including a complete code editor, SLIM IDE, for editing test scripts directly in the browser, complex visualization graphs for comparing test results across runs, and monitoring tests infrastructure for ongoing test health tracking.

Comparison is the part people underestimate. A single run tells you little; the value is in seeing this run against last week’s, against the release before the regression. That shapes how results are stored, not just how they are drawn.

Mac installer

We developed a native macOS application that automates Testable installation, downloading all necessary components and configuring the local environment. Users can set up their Mac as a test runner node without touching the command line.

This matters because the people who most need local test runners are often not the people most comfortable in a terminal. Removing that step widened who inside a customer’s organisation could actually use the platform.