Gradual ramp-upBreakpoint identifiedOperated by our teams
A sales promotion, a TV appearance, or the opening of ticket sales. A stress test simulates the rush before it actually happens, so you know your breaking point instead of finding out in real time.
An infrastructure sized based on averages holds up very well—until the day it no longer does. And what breaks first is almost never what we anticipated: it’s a database overwhelmed by a query from the order processing pipeline, or a third-party service that limits the number of calls. Load testing is specifically designed to uncover that exact sequence of failures, under cold-start conditions.
The load is generated by your actual business scenarios. A simulated user logs in, searches, and places an order, just like a real user.
The volume is gradually increased to identify the threshold at which response times begin to deteriorate, and then the threshold at which errors begin to occur.
Database, third-party service, queue, memory. The analysis identifies the weak link rather than drawing a general conclusion.
A test campaign is planned in advance of a commercial operation, using a representative environment.
Mr Suricate a no-brainer, because he gives you the assurance that there are no problems. Finding just one bug is enough to make the solution pay for itself for an entire year!”
Anthony CornevinE-commerce Platform Manager, Vertbaudet
GO FURTHER
Fifteen types of tests, four categories. Each one answers a different question about your application.
Is there a term you don't understand? The automated testing glossary defines it.
YOUR QUESTIONS
The most common questions we get about load shooting.
The performance test measures the response time of a workflow under normal, continuous usage conditions. The load test pushes the system to its limits by simulating a massive influx of simultaneous users over a short period of time. One monitors performance, while the other determines system capacity.
Our Teams. Load testing is a service we provide—not a feature you simply launch from the platform: we prepare the test scenarios, calibrate the load levels, launch the campaign on the date agreed upon with you, and report the failure point along with the component that fails first.
In an environment representative of production; otherwise, the resulting figure is meaningless. Running the test on an undersized pre-production system yields a pessimistic failure point, and running it on the production system requires strict precautions regarding the data used.
The volume is based on your target, using your historical peak and expected growth as a starting point. A good starting point is rarely a round number: it’s the traffic recorded during your last campaign, multiplied by your target factor.
Prior to any event that drives a surge in traffic: a sales promotion, a product launch, the start of ticket sales, or a media campaign. And after any major architectural changes, because the weak link shifts.
It serves two purposes: sizing the infrastructure and fixing the component that fails first. The second one is often the most beneficial, because a single bottleneck can limit the performance of the entire chain.
A 30-minute demo of your own app. You'll see one of your workflows automated in real time, without writing any code.