Performance Testing

In January, Fernway's summer sale begins — and ten thousand travelers arrive in the same hour. Every feature works perfectly for one user; whether anything works for ten thousand at once is a different question entirely, and performance testing is the discipline that answers it before the crowd does. This chapter's deal, stated once for all four topics: these are specialist fields with whole careers inside them; your goal is conversational fluency — the vocabulary, the core questions, and knowing when to call the specialist. That's exactly what postings and interviews expect of a junior QA generalist.

Bridges got this right a century before software. One truck crossing a new bridge proves nothing about rush hour — so engineers load it to design capacity, then past it in controlled tests, and watch it under years of traffic. Nobody discovers a bridge's limit from the morning commute. Software teams that skip the load test do exactly that.

The Questions It Asks

Three, fundamentally. How fast for one user? — response time: click to answer, the quality travelers actually feel. How many at once? — throughput and capacity: requests handled per second before things degrade. What breaks first, and how? — the bottleneck: every system has a weakest component (the database, a search service, a payment queue), and finding it before the sale does is the whole game. Note what happened to your Chapter 3 vocabulary: "how fast?" was the non-functional requirement nobody wrote — performance testing is how the written version ("search under 2 seconds at 500 concurrent users") gets verified.

Four Shapes of Load

Map a worry to its type and you're already conversant: "will the sale kill us?" is load plus spike; "how big can we grow?" is stress; "why does staging get weird every Thursday?" smells like a soak-detectable leak. The types differ by question, not machinery — the same tools run all four.

Metrics: Why Averages Lie

Here's the field's most important habit of mind. Say search answers in 0.5 seconds on average — sounds fine. But averages hide the tail: if 9 requests take 0.3s and the tenth takes 8s, the average is a pleasant 1.07s while every tenth traveler suffers. So the profession reports percentiles: the 95th percentile (p95) is the time within which 95% of requests finish — equivalently, how bad it gets for the unluckiest 1-in-20. "p95 under 2 seconds" is a promise about nearly everyone; "average 2 seconds" is a promise about no one in particular. Alongside percentiles: error rate under load (systems often fail before they slow — errors climb while response time still looks fine), and the knee: the load level where response time stops degrading gracefully and turns sharply upward. Below the knee, more users cost milliseconds; above it, everything avalanches. Finding the knee is what stress tests are for — and why "test with 50 users and multiply" doesn't work: degradation is non-linear, and the knee can't be extrapolated, only found.

How It's Actually Done

Nobody hires ten thousand people. Load generators — JMeter and k6 from Topic 40's map — simulate them: scripted virtual users searching, booking, paying, at whatever volume and shape the test type demands, while the team watches response times, error rates, and each component's vital signs. One requirement makes or breaks the whole exercise: the environment must resemble production — Chapter 2's lesson at scale. Load-testing a staging environment one-tenth production's size produces numbers that mean nothing about the sale; teams either test against production-sized replicas or (carefully, Chapter 11 will say more) against production itself in quiet hours. The numbers are only as honest as the environment they came from — put that sentence in your pocket for the first performance meeting someone invites you to.

Last January, and This One

Fernway ran the experiment for you, the expensive way. Last year's sale: search slowed to nine seconds (the Chapter 3 complaint — now fully explained: nobody had load-tested, and search hit its knee), checkout errors spiked at the surge, and the team scaled up servers in a panic while travelers rage-refreshed. This year: a load test two weeks early — k6 simulating the forecast, plus a spike shape for the opening minute — finds search hitting its knee at half the expected traffic. The bottleneck: the search service's database queries. Omar's team fixes it with two weeks of calm instead of one night of panic; the sale runs, and nothing happens. Which is the discipline's strange success condition: quiet is the win. Your role as QA generalist in that story: you spotted the missing performance requirement (Chapter 3), asked for the load test in planning (Chapter 5's risks section — "seasonal spike, untested"), and read the p95 chart when the specialist shared it. Conversational fluency, doing its job.