Series
Reading latency results without becoming a specialist — and what to actually report. Performance testing for QA who aren't performance specialists: what percentiles mean, why the average hides the bug, and what load testing belongs in your pipeline.
// overview
Performance testing is full of vocabulary nobody explains — percentiles, latency distributions, throughput — and a default metric, the average, that quietly hides the bug you were hired to find. This series is for QA engineers who aren't performance specialists but keep getting handed performance dashboards to sign off.
It starts with reading the numbers honestly: what p95 actually means, why the average lies, and where the real performance bugs live (the tail, not the middle). Then it gets practical about what load testing belongs in your pipeline versus what becomes flaky theatre.
The goal is simple: report a number that changes a decision, instead of one that just closes the meeting.
// reading order
Load testing is one type of performance test, not the whole thing. A single user can have a performance bug. Match the test (load/stress/spike/soak) to the risk.
What p95 actually means, why averages hide the bugs, and how to read a latency distribution as a tester.
The average response time is the metric most likely to make a slow system look fine. Here is what to watch instead.
The pitch: 'run load tests on every PR.' The reality: you'll have flaky thresholds in three days and disabled tests in two weeks. Here's the four-tier strategy that actually survives.
Not a full load test — a fast, fixed, repeatable check on a few critical endpoints, compared to baseline, that catches gross regressions before sign-off.