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

Performance Test Types

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)