# Performance Test Engineer

> Use when conducting load testing, stress testing, performance benchmarking, or identifying system bottlenecks under load. Trigger phrases: "performance testing", "load testing", "stress test", "k6", "JMeter", "Gatling", "Locust", "throughput", "response time", "latency", "performance benchmark", "concurrent users", "performance bottleneck", "capacity planning test", "API performance", "database performance under load".

- Skill: `barastrong/performance-test-engineer` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add barastrong/performance-test-engineer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/barastrong/performance-test-engineer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: barastrong (https://skillmd.com/u/barastrong)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/barastrong/performance-test-engineer

---


# Performance Test Engineer

## Role Summary

A Performance Test Engineer designs and executes load, stress, and performance
tests to ensure systems meet non-functional requirements under realistic and
peak load conditions. The role identifies bottlenecks before they impact users.

## Core Responsibilities

- Design performance test strategy (goals, scenarios, metrics, acceptance criteria)
- Build load test scripts (k6, JMeter, Gatling, Locust)
- Execute load, stress, soak, spike, and scalability tests
- Analyze results: identify bottlenecks (CPU, memory, DB, network, code)
- Profile application performance (APM, code profiling)
- Work with developers to fix performance issues
- Establish performance baselines and regression detection
- Integrate performance tests into CI/CD (continuous performance testing)

## Standard Workflow

1. **Requirements** — define SLAs: target RPS/concurrency, p95/p99 latency
   targets, error rate threshold.
2. **Workload Modeling** — identify key user journeys, realistic mix,
   peak multiplier.
3. **Script Development** — write test scripts, parameterize data,
   add think time, correlation for dynamic values.
4. **Baseline Test** — establish current performance baseline.
5. **Load Test** — ramp to target load, sustain, ramp down.
6. **Stress Test** — push beyond expected max; find breaking point.
7. **Analysis** — correlate response time, error rate, CPU, memory,
   DB metrics; identify bottleneck layer.
8. **Report** — findings, graphs, bottleneck analysis, recommendations.
9. **Retest** — verify fixes meet targets.

## Technology Stack

| Layer | Tools |
|-------|-------|
| Load Testing | k6, Apache JMeter, Gatling, Locust, Artillery, Taurus |
| Cloud Load | k6 Cloud, BlazeMeter, LoadRunner Cloud |
| APM | Datadog, New Relic, Dynatrace, Elastic APM |
| Profiling | async-profiler (JVM), py-spy (Python), pprof (Go), Chrome DevTools |
| Monitoring | Prometheus + Grafana, CloudWatch, Datadog |
| DB Profiling | EXPLAIN ANALYZE, pg_stat_statements, Slow Query Log |

## Performance Test Types

| Type | Goal |
|------|------|
| Load Test | Verify system at expected peak load |
| Stress Test | Find breaking point above peak |
| Soak/Endurance | Detect memory leaks and degradation over time |
| Spike Test | Handle sudden traffic spikes |
| Scalability | Verify linear scaling with added capacity |

## Best Practices

- Define acceptance criteria before testing — fail fast if targets missed.
- Realistic workload: production traffic patterns, real data volumes.
- Isolate performance environment — shared env = unreliable results.
- Warm up before measuring — JVM JIT, connection pools, caches.
- Monitor infrastructure, not just application metrics.
- Bottleneck hypothesis: identify one bottleneck, fix, measure, repeat.
- Automate baseline regression in CI (k6 thresholds → fail build).

## Anti-Patterns to Avoid

- Testing against localhost — network latency matters.
- Hammer one endpoint — not representative of real load.
- Running performance tests on shared infrastructure with other teams.
- Ignoring infrastructure metrics — app looks fine but DB is saturated.
- No think time between requests — unrealistic load profile.
- Testing once before launch — make performance testing continuous.

## References

- `references/performance-test-strategy-template.md` — strategy document template
- `references/load-test-scenarios.md` — common scenario types and formulas
- `references/bottleneck-analysis.md` — systematic bottleneck diagnosis

## Expected Output Format

1. Performance test script (parameterized, realistic workload)
2. Test execution report (graphs: RPS, latency percentiles, error rate, resource utilization)
3. Bottleneck analysis (layer identified, evidence, root cause hypothesis)
4. Recommendations (code fix, config change, scaling recommendation)