Where Your Load Testing Target Number Should Actually Come From

An SDET gets asked to "load test the checkout flow before Black Friday" and the first question nobody answers precisely is: load test it against what, exactly. Someone in a planning meeting says a thousand concurrent users, because it sounds like a big, safe number. The test runs, the system holds, everyone moves on. Six months later traffic doubles and nobody can say whether a thousand was ever the right number to begin with, because nobody wrote down where it came from. This post is about fixing that: deriving a load target from your own traffic instead of inventing one, and writing the derivation down where the next person can check it.

Load testing, plainly, and how it differs from stress testing

Load testing checks whether a system holds up under the traffic you actually expect, at a specific target level. Stress testing pushes past that target on purpose, to find out where and how the system breaks. The distinction in one sentence: load testing answers "can we handle a normal busy Friday," and stress testing answers "what happens on the Friday that's worse than we planned for." Both matter, but they answer different questions, and a target number derived for one shouldn't be reused unexamined for the other.

The derivation, worked through

The made up number problem is really a shortcut problem. Deriving a real target takes four steps, and none of them require guessing.

Start with real peak traffic. Pull your actual peak requests per minute or peak concurrent sessions from the last real high traffic period, not an average day. If your analytics show a peak of 400 concurrent sessions during last year's biggest sale, that's your starting number, not a round figure someone remembers.

Convert to concurrent sessions on the path you're testing. Not every session hits checkout. If 400 concurrent sessions on the site translate to roughly 60 concurrent sessions actively in checkout, based on your own funnel data, that's the number that matters for this test.

Apply a growth assumption, and name it. This is the step almost everyone skips or buries. If the business expects 30% year over year growth, and marketing has planned a push that historically doubles peak traffic for one day, write both of those down as explicit multipliers: 60 times 1.3 times 2 gives a target of roughly 156 concurrent checkout sessions.

Round up to a defensible target, not an arbitrary one. Call it 160 or 175 concurrent sessions. The number itself now has a paper trail: real peak data, a real funnel ratio, and a named growth assumption, each of which someone can question and update.

Why the derivation belongs on the test case, not just the test run

The number is only half the value. The other half is writing down how you got there, attached to the test case itself, not left in a Slack message or someone's head. A year from now, when traffic patterns have shifted and someone reopens this test case, they need to be able to tell whether 160 concurrent sessions is still the right target or a stale guess from a planning cycle that's long over. If the derivation is written down, including the peak traffic figure, the funnel ratio, the growth assumption, and the date they were pulled, that person can update one input and get a new, equally defensible target. If it isn't written down, they're back to guessing in a meeting, which is exactly the problem this whole exercise was meant to fix.

Who actually runs the test, said honestly

Deriving the target is a documentation and analysis problem. Generating the actual load, the thousand simulated sessions hitting checkout at once, is a separate job done by dedicated load testing tools built for that purpose. Tesbo helps you document the test case, its target, and the reasoning behind that target, and record the outcome once the run happens. It does not generate load or measure throughput itself. Being clear about that division keeps the derivation honest: it's a decision worth writing down carefully precisely because the execution tool downstream will only be as good as the target it's pointed at.

Closing example: the payments load case, written down

Consider a payments team preparing for a subscription renewal spike that historically hits on the first of the month. Their real peak from last quarter's renewal day was 220 concurrent sessions hitting the payment endpoint specifically, pulled from actual log data rather than a guess. Their growth assumption, agreed with finance, is 15% year over year based on subscriber count trends. That gives a derived target of roughly 250 concurrent sessions, which they round to 260 and write into the test case along with the source data and the date it was calculated. When someone reopens this case next quarter, they don't start from scratch. They check whether 15% growth still holds, adjust the number if it doesn't, and move on. That's the whole point: the target survives the person who first calculated it.