What we test
Different performance questions need different test designs. An engagement typically combines several of these, chosen against your objectives during planning.
Load Testing
Measures how the system performs under normal and peak expected conditions. We simulate a large number of concurrent users over a defined period, following realistic user scenarios, and record response times, throughput, and error rates as the load holds. This establishes whether the system meets its performance targets at the traffic levels you actually anticipate.
Stress Testing
Pushes the load up step by step, beyond expected peaks, until the system fails or becomes unstable. The goal is to find the breaking point: the maximum capacity the system can sustain, which component gives out first, and how the failure presents (graceful degradation, cascading errors, or a hard crash).
Endurance / Soak Testing
Holds a normal load for a long run of at least 8 hours to surface issues that only appear over time. Memory leaks, connection-pool exhaustion, log files filling disks, and gradual resource depletion all pass a short test without a trace; a soak test catches them before they take down production.
Spike Testing
Evaluates how the system responds to a sudden surge of users (the flash-sale moment, the viral post, the notification sent to every customer at once), and, just as importantly, how it behaves when the surge subsides. A system that survives the spike but never returns to normal has still failed the test.
An application that works perfectly for ten users can fall over at ten thousand. Nothing in the code has to be wrong for that to happen: a connection pool sized for development traffic, a database query that was fast against a small table, a cache that was never asked to evict anything. These problems are invisible in functional testing and in day-to-day operation, right up until a launch, a marketing campaign, or an ordinary Monday morning puts real concurrent load on the system. By then the cost is lost transactions, abandoned sessions, and users who do not come back. Slow response times cost the same way, more gradually: the system stays up, but every interaction erodes trust.
How we work
Load and stress testing answers the questions functional testing cannot: how many concurrent users can this system actually serve, where does performance start to degrade, what breaks first when demand exceeds capacity, and does the system recover cleanly afterwards. We simulate realistic user behaviour at scale, measure how the system responds, and turn the results into findings your engineering team can act on: named bottlenecks with recommendations attached.
Planning
We define the objectives with you: which test types apply, what "good" looks like (target response times, acceptable error rates, required concurrent users), and which user journeys matter most.
From that we build realistic scenarios and load profiles that reflect how your users actually behave: the mix of browsing, searching, and transacting.
Execution
We run the agreed tests using industry-standard load-testing tools, generating load against the target environment while monitoring the system's behaviour throughout.
Tests are scheduled and coordinated with your team so that a deliberate stress test is never mistaken for a real incident.
Analysis
Raw metrics become findings: where the bottlenecks are, how response times behave as load climbs, which resources (CPU, memory, database connections, network) hit their limits first, and at what point the system stops meeting its targets.
Each finding comes with a recommendation.
Re-test
After your team applies fixes, we re-run the relevant tests under the same conditions to confirm the improvement is real and measurable.
What you get
Every report contains, at minimum, the following.
Executive summary
The capacity and risk picture in business terms, suitable for management: what the system can handle today and where the limits are.
Detailed performance report
Throughput, response times at each load level, error rates, and resource utilisation across the test runs, with the test design documented so results are reproducible.
Bottlenecks and breaking points
The specific components that constrain performance, the load at which the system becomes unstable, and how it fails when it does.
Optimisation recommendations
Practical improvements across hardware, software, and configuration: where scaling out helps, where tuning helps more, and which fixes buy the most capacity for the least effort.
Test design, execution, performance analysis, and optimisation guidance are all part of the engagement.
Team credentials
Performance testing at Incognito Lab is run by the same team that delivers our security assessments, with the same method: reproducible tests, validated results, and findings your engineers can act on. See the certifications the team holds.
When you need it
Three situations reliably justify a performance test.
Before a major launch or campaign
When you know traffic is coming and need confidence the system will hold, with time left to fix what doesn't.
After significant architecture changes
A migration, a new database, a re-platformed service: previous performance results no longer apply, and assumptions carried over from the old architecture are exactly where surprises hide.
To establish a capacity baseline
Knowing your current ceiling informs scaling decisions and infrastructure budgets, and gives you a reference point to measure every future change against.
Last reviewed: 12 Oct 2026
LOAD TEST / STRESS TEST
We define the objectives with you: which test types apply, what "good" looks like, and which user journeys matter most.
From our team
Tell us what the system has to survive
The planning conversation is short. Tell us what the system does and what you expect it to survive, and we will design the test around it.
