Performance Testing Process

A performance engagement runs through eight phases, from the first client conversation to a signed-off report, with four quality gates in between. As a tester you spend most of your time in phases 4 to 7, but knowing the whole flow tells you where your inputs come from and who uses what you hand over.

Process at a glance

Phases 6 and 7 loop until the exit criteria at G4 are met. Monitoring and control runs across every phase, so the client hears about progress and risks early, not only in the final report.

Your part as a tester

The tester owns phases 4 to 7 and feeds the lead's work in the others.

Phase	Who leads	Your part as a tester	You hand over
1 Requirements gathering	Perf test lead + client	Join the workshop if invited; note how each flow is really used; flag flows that look hard to script	Open questions on flows and data
2 Performance risk assessment	Perf test lead + architect	Share what you know about heavy screens, slow queries and integrations	Input to the risk register
3 Test approach and plan	Perf test lead	Check the workload model can be scripted; estimate your scripting and execution effort	Effort estimate, review comments on the plan
4 Environment and test data setup	Tester + infra	Prepare test data; check injectors, monitoring and access; run the environment smoke test	Environment checklist, test data sets
5 Test design and scripting	Tester	Script, get peer review, smoke at 1 user, then sanity checks on all test users in batches as a scaled smoke (client approval)	Reviewed scripts, smoke and sanity results (evidence for G3)
6 Test execution	Tester	Run the booked tests; watch live metrics; log every run with its config	Raw results, run log
7 Analysis and tuning	Tester + dev	Find bottlenecks, raise defects with evidence, retest fixes	Defect log, retest results
8 Reporting and closure	Perf test lead	Supply results, charts and lessons learned; archive scripts, data and results	Analysis input, archived testware

The team also measures its own testing. The run logs, defect counts and retest cycles you record in phases 6 and 7 feed those metrics.

Phases in detail

Each phase ends with a named output. A gate blocks the next phase until its owner approves.

#	Phase	Key activities	Inputs	Outputs	Owner	Exit gate
1	Requirements gathering	Client workshop; capture NFRs (response time, throughput, error rate, resource limits); peak and average business volumes; critical user flows; growth forecast; test windows and constraints	Client brief, business volumes, production logs or analytics, architecture diagram	Signed NFR sheet, critical flows list, open-question log	Perf test lead + client BA/PO	G1 NFRs signed off by client
2	Performance risk assessment	Rate each flow by business impact and load risk; flag risky components (DB, integrations, batch jobs); agree what is in and out of scope	NFR sheet, architecture, change list for the release	Performance risk register, prioritised flow list	Perf test lead + solution architect	Risks reviewed with client
3	Test approach and plan	Choose test types (baseline, load, stress, soak, spike); build workload model from volumes; set entry/exit criteria; plan schedule, effort, tools, environment and data needs	Risk register, NFR sheet	Performance test plan, workload model, entry/exit criteria	Perf test lead	G2 Test plan approved by client and PM
4	Environment and test data setup	Confirm prod-like environment and its gaps; set up load injectors and monitoring (APM, server metrics, DB); generate and load test data; confirm firewall and access	Test plan, environment specs	Environment readiness checklist, test data sets, monitoring dashboards	Perf tester + infra/DevOps	Environment checklist complete
5	Test design and scripting	Record flows; correlate dynamic values; parameterise data; add think time and pacing; peer review scripts; run a single-user smoke test, then sanity checks on all test users in batches, run as a scaled smoke (client approval needed)	Critical flows, workload model, test data	Peer-reviewed scripts, smoke results, sanity check results for all test users	Perf tester	G3 Test readiness review passed
6	Test execution	Book the run window with the client; run baseline first, then load, stress, soak and spike as planned; watch live metrics; log every run with its config	Ready scripts, environment, schedule	Raw results (.jtl), server and APM metrics, run log	Perf tester	All planned runs complete
7	Analysis and tuning	Compare results to NFRs; find bottlenecks from metrics; raise performance defects; retest after each fix (loops back to phase 6)	Run results, NFR sheet	Defect log, tuning notes, retest results	Perf tester + dev team	G4 Exit criteria met or accepted by client
8	Reporting and closure	Write report against NFRs; give go/no-go recommendation; hold lessons-learned session; archive scripts, data and results	All results, defect log	Final test report, client sign-off, archived testware, lessons learned	Perf test lead	Client sign-off

The JMeter guides cover the hands-on part of several phases: Understand Requirements (phase 1), Design Load Model (phase 3), Execute & Analyze (phases 6 and 7) and Reporting (phase 8).

From scripts to the real run

We only book the real run with the client once the scripts have passed the smoke test and sanity checks on every test user. A failed run in the client's booked window wastes their team's time and our credibility.

• Smoke test (1 user): proves the script logic. Correlation, parameterisation and assertions all work, and every request returns what we expect.
• Sanity checks with scaled smoke (all test users): every test user in the data runs through the scripts, batch by batch (for example 100 users at a time for a 5,000-user target). This proves each record can actually be used (accounts log in, IDs exist, nothing is locked or already used up). Because each batch runs concurrently, it also covers what one user cannot: sessions don't collide, injectors cope and monitoring captures server metrics.
• Client approval for the sanity run: it puts real concurrent load on the client's environment, so agree the time slot and batch size with them first.
• Booking the run: agree the date and time window, an environment freeze, who is on call from infra and dev, and how test data is reset afterwards.

Tips

• Ask for the sanity run approval at G2. If the test plan already names the sanity run with its batch size, you only need to confirm the date later, not ask again.
• Split test data into batch files for sanity. In JMeter, point the CSV Data Set Config at one batch (for example users_batch_01.csv), set Recycle on EOF to False and Stop thread on EOF to True, so every row is used exactly once. A row that fails an assertion is a bad record, not a script bug.
• Keep the sanity results per batch. If a user fails in the real run, check its sanity result: passed in sanity means the load caused it, failed in sanity means the data did.
• Distributed runs need the sanity run most. It is the first time all load generators fire together, and a misconfigured one usually shows up in the first few minutes.