Load Test Execution Plan Template

Overview

Load testing evaluates how a system behaves under realistic or peak traffic. This template helps teams define test goals, select scenarios, prepare environments, execute tests, and document results. It ensures that performance work is repeatable and tied to clear success criteria.

When to Use

• For alternatives, see Logging, Monitoring & Observability Guide.

• Before a major product launch or marketing campaign.

• After major architecture or infrastructure changes.

• When scaling targets or user growth projections change.

• When latency or error rate issues appear under load.

• As part of a regular performance regression test suite.

• Before capacity planning or cost optimization work.

Prerequisites

• A production-like test environment that mirrors topology and data.
• Load testing tools such as k6, JMeter, Gatling, or Locust.
• Monitoring and observability for the system under test.
• Baseline metrics from normal production traffic.
• Clear ownership and a scheduled test window.
• A rollback or scaling plan if the test reveals problems.

Solution

Template

1. Test Goals and Scope

Field	Description	Example
Test ID	Unique identifier	LT-2026-Q3-001
System under test	Application or service	Checkout API
Test date	When the test runs	2026-06-27
Test owner	Responsible engineer	Performance team
Stakeholders	Teams to notify	SRE, backend, platform, product
Goal	Why the test is run	Validate checkout handles 10x traffic at launch
Scope	What is included	API endpoints, database, cache, queue
Out of scope	What is not tested	Payment processor, third-party integrations

2. Test Scenarios

Scenario ID	Description	Endpoint / Flow	Virtual Users	Ramp Up	Duration	Think Time
S01	Browse catalog	GET /products	500	2 min	10 min	1-3 s
S02	Add to cart	POST /cart/items	300	2 min	10 min	1-3 s
S03	Checkout	POST /orders	200	2 min	10 min	2-5 s
S04	Search	GET /search?q=...	400	2 min	10 min	1-2 s
S05	Peak burst	All endpoints combined	2000	5 min	15 min	0-1 s

3. Success Criteria

Metric	Baseline	Target	Must Stay Below	Notes
p50 latency	45 ms	< 60 ms	80 ms	For API responses
p95 latency	120 ms	< 150 ms	200 ms	For API responses
p99 latency	300 ms	< 400 ms	600 ms	For API responses
Error rate	0.01%	< 0.1%	0.5%	HTTP 5xx and timeouts
Throughput	1000 RPS	> 2000 RPS	-	Orders per second
CPU utilization	40%	< 70%	80%	Per application node
Memory utilization	50%	< 70%	85%	Per application node
Database connections	80	< 150	200	Active connections
Queue depth	10	< 50	100	Background jobs

4. Environment Setup

Resource	dev/test	production	Notes
Application nodes	2	6	Same instance size
Load balancer	1	2	Same configuration
Database	Single instance	Multi-AZ cluster	Same major version
Cache	1 node	3 nodes	Same engine version
Message queue	1 node	3 nodes	Same configuration
Load generator	4 injectors	N/A	Cloud instances or containers
Network	Isolated VPC	Production VPC	Mirror latency and topology
Data volume	10% of production	Full production	Use anonymized data

5. Execution Plan

Step	Action	Owner	Time
1	Verify environment and monitoring	SRE	T-30 min
2	Reset environment to known state	SRE	T-20 min
3	Deploy test scripts and data	Performance team	T-15 min
4	Run baseline test at low load	Performance team	T-10 min
5	Execute scenario S01-S04	Performance team	T0
6	Execute peak scenario S05	Performance team	T+15 min
7	Monitor system and collect metrics	SRE	T+15 to T+30 min
8	Gradually reduce load and stop test	Performance team	T+30 min
9	Export results and logs	Performance team	T+35 min
10	Restore environment	SRE	T+45 min

6. Results and Analysis

Scenario	Max VUs	Peak RPS	p95 Latency	p99 Latency	Error Rate	CPU Avg	Memory Avg	Result
S01	500	1200	55 ms	180 ms	0.01%	45%	60%	Pass
S02	300	800	90 ms	250 ms	0.02%	55%	65%	Pass
S03	200	450	140 ms	380 ms	0.05%	60%	70%	Pass
S04	400	950	70 ms	210 ms	0.01%	50%	62%	Pass
S05	2000	3400	220 ms	700 ms	0.8%	85%	88%	Fail

7. Findings and Remediation

Finding ID	Description	Severity	Recommendation	Owner	Due Date
LT-001	Database connection pool exhausted during peak	High	Increase pool size and add connection retry	Backend team	2026-07-04
LT-002	Cache hit ratio drops under search load	Medium	Add search result caching and tune TTL	Backend team	2026-07-11
LT-003	Queue depth grows when order rate exceeds consumer capacity	Medium	Scale background workers horizontally	Platform team	2026-07-11

Explanation

Load testing is not just about finding the breaking point. It is about understanding how a system degrades, where the bottlenecks are, and whether the current capacity meets user and business expectations. A documented execution plan makes performance testing repeatable, comparable across releases, and useful for engineering teams.

k6 Load Test Script Example

import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate } from 'k6/metrics';

const failureRate = new Rate('check_failure_rate');

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 300 },
    { duration: '5m', target: 300 },
    { duration: '2m', target: 500 },
    { duration: '5m', target: 500 },
    { duration: '2m', target: 2000 },
    { duration: '5m', target: 2000 },
    { duration: '5m', target: 0 },
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    http_req_failed: ['rate<0.01'],
    check_failure_rate: ['rate<0.05'],
  },
};

export default function () {
  const correlationId = `corr_${__VU}_${__ITER}`;
  const headers = {
    'X-Correlation-Id': correlationId,
    'Content-Type': 'application/json',
  };

  const loginRes = http.post('https://api.example.com/auth/login', JSON.stringify({
    username: `user_${__VU % 100}`,
    password: 'test-password',
  }), { headers });

  check(loginRes, {
    'login status 200': (r) => r.status === 200,
    'login has token': (r) => r.json('token') !== undefined,
  });

  failureRate.add(!check(loginRes, {
    'login success': (r) => r.status === 200,
  }));

  sleep(Math.random() * 2 + 1);

  const listRes = http.get('https://api.example.com/orders', {
    headers: { ...headers, Authorization: `Bearer ${loginRes.json('token')}` },
  });

  check(listRes, {
    'orders status 200': (r) => r.status === 200,
    'orders has items': (r) => r.json('items').length > 0,
  });

  sleep(Math.random() * 3 + 1);
}

Variants

• Spike test plan: Focus on sudden traffic bursts and recovery behavior.
• Stress test plan: Push the system beyond expected limits to find failure modes.
• Endurance test plan: Run moderate load for hours or days to detect memory leaks or drift.
• Soak test plan: Long-running test at production-like load to validate stability.
• Scalability test plan: Increase load while adding resources to measure scaling efficiency.
• Browser-based load test plan: Use real browser sessions to measure frontend and API performance together.

What Works

• Test in a production-like environment with representative data and traffic patterns.
• Define success criteria before running the test.
• Start with a baseline and increase load gradually.
• Monitor both application metrics and infrastructure metrics.
• Run tests multiple times to confirm reproducibility.
• Include business metrics such as conversion rate or transaction throughput.
• Document findings and assign owners before closing the test.
• Automate regression tests in CI/CD for critical paths.
• Coordinate with the team to avoid impacting production or shared environments.

Common Mistakes

• Running load tests directly against production.
• Using synthetic traffic that does not match real user behavior.
• Testing only one endpoint instead of the full user journey.
• Ignoring cold start, cache warm-up, or database seeding effects.
• Not involving the platform or SRE team during execution.
• Setting success criteria that are too lenient or undefined.
• Running tests once and never repeating them after changes.
• Failing to correlate infrastructure metrics with application latency.

Troubleshooting

• Largest Contentful Paint is high: optimize images, preload critical resources, and reduce server response time.
• JavaScript bundle size grows: analyze the bundle, split code by route, and tree-shake unused dependencies. Lazy-load non-critical components.
• Cache hit rate is low: review cache keys, TTLs, and invalidation patterns.
• Database CPU spikes: find the top queries by execution time and frequency. Add indexes, rewrite queries, or cache results.
• Throughput drops under load: profile for contention, garbage collection, and blocked threads. Scale horizontally only after optimizing the hot path.

Further Reading

• Official documentation: check the current reference for the framework or tool used.
• Related guides: explore the load-testing and performance guides for deeper coverage.
• Complementary patterns: review design patterns applicable to your technology stack.
• Public postmortems: study real incidents from teams that faced similar production issues.

Production Notes

• Deploy gradually using canary or blue-green to catch regressions early.
• Configure alerts for error rate, p99 latency, and failure rate before enabling in production.
• Document the rollback in the runbook; test the procedure in staging at least once per quarter.
• Review structured logs with correlation IDs to trace requests end-to-end during incidents.

Key Takeaways

• Apply load test execution plan template when you need a practical solution for your use case.
• Monitor performance after implementation; measure latency, errors, and resource usage before and after.
• Check the Troubleshooting section for common failures; most have documented root causes with fixes.
• Keep dependencies updated and run tests in CI to prevent production regressions.

Common Production Pitfalls

• Leaving required fields blank or using vague one-word answers.
• Filling the document once and never updating it after scope or decisions change.
• Storing the document where the team does not look during incidents or reviews.
• Not assigning an owner, due date, or review cadence.
• Copying boilerplate without removing sections that do not apply.
• Skipping version control, which makes rollback and accountability impossible.
• Failing to link the document to related decisions or follow-up actions.
• Avoiding quarterly reviews that would retire stale or unused sections.