LOAD TEST / STRESS 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 measured in lost transactions, abandoned sessions, and users who quietly decide not to come back. Slow response times do the same damage in slow motion: the system stays up, but every interaction erodes a little more trust.

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 — not a wall of graphs, but named bottlenecks with recommendations attached.

What we test

Different performance questions need different test designs. An engagement typically combines several of the following, 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 scenarios rather than hammering a single endpoint, 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. Knowing the ceiling is what turns capacity planning from guesswork into arithmetic.
• 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 is how they get caught before they take down production at 3 a.m.
• 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.

How we work

Every engagement runs through the same phases, so you always know where the project stands and what arrives next.

1. 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, not a synthetic worst case that proves nothing.
2. 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.
3. 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, not just a number.
4. 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 — the same before-and-after discipline we apply to every assessment we deliver.

What you get

Every report contains, at minimum:

• 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 — you receive a service, not just tool output.

Team credentials

Performance testing at Incognito Lab is run by the same engineering-minded team that delivers our security assessments — people accustomed to instrumenting systems, reading them under pressure, and reporting precisely what they found. The discipline is the same: reproducible method, validated results, and findings your engineers can act on without guesswork. 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 turns scaling decisions and infrastructure budgets into informed choices rather than estimates, and gives you a reference point to measure every future change against.

If any of these describe where you are, 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.