Quality & Testing · master area
Performance / Load Testing
SLO verification in staging, shaped against the expected load profile. Not "does it work fast" — "does it hold the promise the brief made under the load the brief named."*
Owners: QA, Tech Lead Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: Predictions over plans — performance targets are predictions, checked.
Where it lives in the chain
How to do this
The load test is derived from the load profile named in the performance ADR — not made up at test time:
- Load profile — "200 graders submitting simultaneously at end of semester; 50 sustained throughout normal hours." From the brief.
- Test scenario — recreate the load profile in staging. Use real-ish data shapes; not synthetic, not toy.
- SLO assertion — "p95 latency under 800ms at the named load." Pass or fail.
- Bottleneck attribution — when the test fails, which component slowed? Database? Service? Queue? Externalised dependency? The test must produce that answer.
What good practice looks like
The load test runs in CI, against staging, on every release candidate. A failed load test blocks release. Performance is not optimised when convenient — it is verified when promised.
Performance regressions show up first at p95 and p99, not at p50. A team that watches only the median ships features that work for 50% of users while quietly degrading the experience for the rest. The test asserts at the right percentile — the one the SLA promised.
The team's discipline: performance is treated like a feature. Named at shaping (the ility), built into the design (the architecture), verified at release (the load test), watched in production (the SLI). A performance bug found in production is a chain-aware scenario-gap — the load profile wasn't tested at the scale that matters.
Related crafts
- Performance Engineering — the design half
- Ilities Selection — where performance is named as a target