PhraseryPhrasery homeGet Phrasery
Tests & QA21 categories

Design performance test scenarios

Before a launch where load is a real unknown.

Design performance tests for the system below.

1. State the scenarios worth testing: normal peak, the worst realistic spike, sustained load over hours, and the growth expected in a year.
2. For each, the concrete numbers: concurrent users, requests per second, data volume, and the mix of operations. Base these on what I gave you and mark anything you assumed.
3. Define the pass criteria as percentiles, not averages. Say which percentile matters for this system and why.
4. Name what will break first, with reasoning: connection pools, a single query, memory, a third-party rate limit, a queue.
5. Describe what to measure beyond response time: error rate, saturation, queue depth, resource use.
6. Say what not to bother testing, because it will never be the bottleneck here.

System:

Making it yours

  • Paste your own material where the prompt asks for it. Everything above that line is instruction, not content.
  • Delete any rule that does not apply to you. A shorter prompt that fits beats a thorough one that does not.
  • If the answer comes back vague, add a line saying what you do not want. Constraints work better than encouragement.

Beyond unit tests. Manual QA, exploratory charters, accessibility, load, and contracts between services.

Related prompts

Keep this one

Phrasery saves prompts with a right-click and puts them back the same way. Add this to your own library in one click.

Add to your browser โ€” free