Performance Testing: Write Down What "Fast Enough" Means Before You Run Anything

A payments team runs a load test the night before a release. The graph comes back showing average response time climbing from 80ms to 340ms as traffic ramps up. Someone in the release channel asks: is that fine? Nobody answers, because nobody wrote down a number that would count as fine before the test ran. The run gets called "looks okay" and the release ships anyway. Two weeks later checkout at peak feels sluggish and support tickets start piling up. This happens on a normal Thursday in a normal sprint, and it is rarely the load tool's fault. The tool did exactly what it was told. Nobody told it what to check against.

Performance testing has a strange reputation problem online. Nearly every article about it is written by a company selling a load generator, so the whole conversation gets pulled toward which runner is fastest or easiest to script. That is a real question, but it is not the question that actually breaks releases. The question that breaks releases is upstream of any tool: what does fast enough mean for this specific product, and did anyone write that down as something a test could pass or fail against. A performance requirement, stated properly, is an acceptance criterion with a number attached to it. That makes it a documented test case, regardless of what generates the load underneath it.

What performance testing actually covers

Performance testing is the practice of checking whether a system behaves acceptably under realistic and extreme traffic. It is not one test type. It is a family of related checks that share a method and differ in what they push:

• Load testing checks whether the system holds up at an expected traffic level
• Stress testing pushes past that level to see how the system fails
• Spike testing checks sudden, short bursts rather than sustained growth
• Soak testing runs a moderate load for hours to catch memory leaks and slow degradation
• Endurance testing is soak testing's longer, multi day cousin, aimed at the same class of slow drift problems

Each of these deserves its own detailed treatment. What they share matters more than what separates them. All five are pointless without a written threshold, and all five produce evidence, not judgment. The judgment still belongs to the team that wrote the requirement.

Name the tool, and name what it does not do

To be direct about it, tools like k6, JMeter, Gatling, and Locust are the ones that actually generate traffic and run the load. They open connections, send requests, and record timings. That is real, useful, technical work, and it is not what this post is about.

Tesbo does not generate load, does not run performance tests, and does not host runners. What Tesbo is useful for is the half of performance testing that happens before a runner is ever pointed at a system, and the half that happens after the graph comes back. Before the run, that means writing the acceptance criteria as a documented case: what is being tested, under what conditions, and what result counts as a pass. After the run, it means recording the actual result against that stated expectation, so the next person who looks at this case does not have to re derive what "acceptable" meant six months ago.

The threshold is an acceptance criterion, not a hope

A performance test without a written threshold is just a number generator. The threshold turns it into a test. Three things typically need to be pinned down in advance:

• p95 latency: the response time that 95% of requests fall under, expressed in milliseconds
• Error rate ceiling: the maximum acceptable percentage of failed requests during the run
• Concurrency: how many simultaneous users or sessions the system needs to hold at once

Write these down as an expected result, the same way you would write the expected result for a functional case. Given this load profile, the system should keep p95 latency under 400ms with an error rate below 1%. That sentence is short, and it is the entire difference between a test and a demonstration.

One caution here: there is no universal number that applies to every product. A dashboard that refreshes once a minute can tolerate latency that would be unacceptable on a checkout page processing a card. Thresholds have to be derived from what your users actually need from your specific product, not copied from a blog post about somebody else's system.

Why a percentile beats an average

This is the part that trips up teams who are new to reading performance results. Averages hide the exact thing you are trying to find.

Picture ten requests during a load run. Nine of them return in 100ms. One of them, because it happened to land on a database connection under contention, takes 4,000ms. The average across those ten requests is 490ms, which looks mediocre but survivable. The p95 value tells a different story. It says that a meaningful slice of your real users, not a rare outlier, is waiting four seconds for a page to respond. Nine calm requests can mathematically bury one furious one. A percentile keeps that furious request visible instead of diluting it into an average that nobody would actually be upset about.

That is why serious performance requirements are written in percentiles, almost always p95 or p99, rather than averages. It is a small change in vocabulary that changes what the test can actually catch.

A written case for the payments example

Here is what a documented performance case looks like once the threshold is decided in advance rather than argued about afterward, using the same payments example from the opening.

Preconditions: staging environment mirrors production database size at 2.1 million transaction records. Payment gateway sandbox is configured. Baseline traffic pattern is derived from the last 30 days of production analytics.

Load profile: ramp from 0 to 1,200 concurrent checkout sessions over 10 minutes, then hold for 20 minutes.

Expected result: p95 latency on the checkout confirmation endpoint stays under 500ms, error rate stays below 0.5%, and no transaction is double charged.

Whoever runs this, whichever tool generates the actual traffic, the case itself lives independently of the tool. A year from now, when someone asks whether the payments checkout can still hold 1,200 concurrent sessions, the answer is not "let's find out from scratch." It is "here is what we agreed fast enough meant, here is what we tested, here is what happened." That record is the actual deliverable of performance testing. The graph is just the evidence that supports it.

Putting it together

Performance testing done well is less about which tool you point at the system and more about whether anyone was willing to write down, in advance, what fast enough actually meant. The runners do the pushing. The documented case is what turns the resulting graph into a decision.