load-testing-plan

Load Testing Plan Skill

Produce a complete load and performance testing plan for a service — covering test objectives, scenario definitions, tooling configuration, success thresholds, and CI integration. A good load testing plan eliminates ambiguity about what "performance is acceptable" means, so engineers can run tests and get a pass/fail answer without having to interpret raw numbers themselves.

Required Inputs

Ask for these if not already provided:

• Service name and key endpoints — which endpoints are under test (path, method, typical request/response shape)
• Current traffic baseline — current requests/sec, p50/p99 latency, error rate under normal load
• Peak traffic expectations — expected peak RPS (e.g. 10× baseline for flash sales, or seasonality peak)
• SLO targets — latency SLOs (p99 < X ms), error rate SLO (< Y%), availability target
• Preferred testing tool — k6, Locust, JMeter, Gatling, or no preference
• Test environment availability — dedicated load test environment, staging, or production (with traffic shaping)

Output Format

---

Load Testing Plan: [Service Name]

Author: [Name] | Team: [Team name] Date: [Date] | Review cycle: Before each major release and quarterly Testing tool: [k6 / Locust / JMeter / Gatling] Test environment: [Environment name and URL]

---

1. Objectives and Scope

What we are testing: [Service name] handles [describe function — e.g. "user authentication requests from the mobile and web clients"]. This plan validates that the service meets its SLOs under expected and elevated traffic conditions.

In scope:

• [Endpoint 1: METHOD /path — description]
• [Endpoint 2: METHOD /path — description]
• [Endpoint 3: METHOD /path — description]

Out of scope:

• [Any endpoints explicitly excluded and why — e.g. "admin APIs — low traffic, excluded from load test"]
• [Third-party integrations that cannot be load-tested — mock them instead]

---

2. Performance Targets (Success Criteria)