p95 latency explained for QA engineers
What p95 actually means, why averages hide the bugs, and how to read a latency distribution as a tester.
Blog
Investigations under the hood of the tools we use every day. How things actually work — not how the docs say they work.
What p95 actually means, why averages hide the bugs, and how to read a latency distribution as a tester.
The most common serious web vulnerability is also the easiest for QA to catch: the app serves a record by ID without checking it is yours. Two accounts and a changed number find it.
Authentication asks who you are; authorization asks if you are allowed. Most access-control bugs live in the second question — tested with a written access matrix and a lot of negative testing.
Skip the full registry — learn the dozen status codes that carry real meaning, what each promises, and how to spot when the code and the body disagree.
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.
LLMs can't reliably separate instructions from data, so user input can hijack the model. Direct and indirect injection, what to check for, and how to report it QA-safe.
Focus order is the route a keyboard user takes through your page. When it's wrong the page looks perfect and becomes unusable — and scans don't catch it.
The OWASP Top 10 translated for QA: what each category means for flows you already test, and the one check you can run without being a pentester.
QA fresh-installs; real users upgrade in place over old data. Test the upgrade path — schema migrations, stored settings, sessions, multi-version jumps.
A green suite confirms only what you thought to check. Readiness adds coverage-vs-change, accepted risk, observability, and non-functional signals.
Three different tools on a spectrum from prescribed to open: when to write a scripted case, a coverage scenario, or an exploratory charter.
API suites fail on shared, stale, order-dependent data more than on wrong assertions. The own-your-data strategy — independent, unique, cleaned — that keeps them reliable.
Fragmentation, permissions, system-back, lifecycle, hardware layout, and notifications diverge between platforms — so a pass on one isn't evidence for the other.
Derive thresholds from user expectation, today's baseline, and business impact — set on p95/p99 with an error-rate gate, tiered by criticality — not a made-up 'under 2s'.
An honest map of QA's branches — deepening manual, automation, SDET, lead, manager — each rewarding different strengths, none 'up' from the others. Choose by what you like doing.
Cypress retries commands until they pass or time out — but only some commands, and only some of the time. Understanding which is the difference between solid tests and flaky ones.
Cypress has three features that look similar but solve completely different problems. Fixtures are static data. Tasks are Node-side escape hatches. Intercepts are network shape. Here's the boundary.
The Playwright trace viewer is the single feature most arguments for Playwright should lead with. Most teams use 10% of it. Here are the five patterns to look for in every trace.
Cypress retries commands; Playwright auto-waits on actionability. Same problem, different solution. Here's what Playwright is actually doing when you call .click().
Contract testing is two things wearing one name: a model and a tool. The model is genuinely useful; the marketing for the tool oversells where it fits. Here's the model, separated from any vendor's pitch.
Most 'REST vs GraphQL' content is about API design. The testing perspective is different — query construction, schema-aware tooling, the N+1-shaped test bug, and why GraphQL flips the test pyramid.