A Pre-Launch Performance Testing Checklist

Before treating a performance testing effort as “done” ahead of a launch or major release, running through a structured checklist catches gaps that are easy to miss when you’re deep in the details of any one specific test.

Test design

• Is there a specific, written question this testing effort is meant to answer (see this site’s test plan article)?
• Are success criteria defined as concrete numbers, ideally tied to an existing SLO, decided before seeing results?
• Does the load model (closed vs open system) actually match the real traffic pattern being tested for?
• Is test data parameterized realistically, avoiding the same-row contention issue covered in this site’s tool-specific parameterization articles?

Coverage

• Has steady-state capacity been tested, not just a single “looks fine” load level?
• Has a stress/breaking-point test been run to know what failure actually looks like and at what load?
• Have realistic failure scenarios been tested (a downstream dependency slow or unavailable), not just the happy path?
• If relevant, has a soak/endurance test (sustained load over hours, not minutes) been run to catch slow resource leaks that a short test wouldn’t reveal?

Analysis

• Are results reported in percentiles (p95/p99), not just averages?
• Has ramp-up/ramp-down period been excluded from steady-state analysis?
• Has client-side latency been correlated against server-side resource metrics (the USE method, covered in this site’s dedicated article) to understand why, not just that, something was slow?
• Have results been compared against a previous baseline or explicit target, not viewed in isolation?

Infrastructure and environment

• Does the test environment’s scale (database size, number of replica nodes, cache warmth) reasonably resemble production, with documented differences where it doesn’t?
• Has the load generator itself been confirmed not to be the bottleneck (CPU/network headroom checked on the load-generating machine)?
• Have any test-specific configuration differences from production (feature flags, rate limits, monitoring overhead) been documented?

Process

• Is the test script/configuration version-controlled and repeatable, not a one-off manual exercise?
• Has someone other than the test’s author reviewed the results and the test design itself for blind spots?
• Are there concrete action items (not just “results look fine”) if any issues were found, with owners and target dates?
• Is there a plan for re-testing after any fixes, rather than assuming a fix worked without re-validation?

Sign-off

• Have the actual decision-makers for the launch reviewed the results and explicitly signed off, rather than the testing effort happening in isolation from the actual launch decision?

Takeaway: most performance testing gaps aren’t about using the wrong tool — they’re process gaps (no defined success criteria, no server-side correlation, no re-test after a fix) that a structured checklist like this one catches reliably, precisely because they’re easy to skip when focused on the technical details of any single test.