The most expensive time to find a performance problem is in production. The cheapest time is during development. But you cannot performance test everything every day -- it takes time and resources. So when do you test?
Before a major release or product launch -- you are about to expose the system to real users for the first time. You need to know it can handle the expected load.
After significant architecture changes -- new database, new cache layer, API gateway migration, microservice split. Any structural change can introduce performance regressions.
Before expected high-traffic events -- Black Friday, marketing campaigns, product launches, seasonal peaks. If you know traffic will spike, test before it does.
When adding features that increase data volume -- new search functionality, report generation, file upload, real-time notifications. More data means more processing.
After performance-related bug fixes -- you fixed a slow query. Does the fix work under load? Or did it create a new bottleneck somewhere else?
When users report slowness -- complaints about speed are performance test triggers. Reproduce the reported scenario under load to confirm and diagnose.
Traditional teams run performance tests at the end, right before release. By then, fixing issues is expensive -- the code is "done," the deadline is tomorrow. Smart teams shift left -- they run lightweight performance checks earlier in the cycle. An API endpoint that takes 500ms to respond under no load is probably going to take 5 seconds under 100 concurrent requests. You can catch that with a simple benchmark in your CI pipeline, no full load test needed.
Not every performance test needs 10,000 virtual users and a dedicated environment. A quick load test with 50 users against your staging API after every deploy catches 80% of performance regressions. Run it in CI, fail the build if p95 response time exceeds your threshold. Reserve full-scale tests for pre-release milestones.
Q: When should performance testing be done in the software development lifecycle?
A: Performance testing should be integrated throughout the lifecycle, not just at the end. During design, define performance requirements (SLAs like p95 response time under 2 seconds). During development, write unit-level benchmarks for critical paths. In CI, run lightweight API load tests (50 users) after each deploy to catch regressions early. Before release, run full load, stress, and spike tests on a staging environment that mirrors production. The shift-left approach catches 80% of issues early when they are cheap to fix. Full-scale tests before release catch the remaining 20%.
Key Point: Test early and often. Quick CI checks with 50 users catch most regressions. Full-scale tests before releases, architecture changes, and high-traffic events catch the rest. Never find performance bugs in production.
Key Point: Shift left -- run lightweight load tests in CI after every deploy, full-scale tests before releases and high-traffic events