English for k6 Load Testing

k6 is a widely adopted open-source load testing tool that lets engineers simulate thousands of virtual users hitting their services. If you work on performance testing and collaborate with English-speaking colleagues, you will regularly need to discuss test scenarios, interpret results, and present findings. This post covers the vocabulary and phrases that make those conversations clear and professional.

Key Vocabulary

Virtual user (VU) A virtual user is a simulated user that executes the test script concurrently with other virtual users. The number of virtual users running simultaneously is the primary measure of load. Example: “We ramped up to 500 virtual users over five minutes and held that level for ten minutes.”

Throughput Throughput in load testing refers to the number of requests completed per unit of time, typically expressed as requests per second (RPS). Higher throughput indicates the system can handle more load. Example: “At 500 VUs, we achieved a throughput of approximately 1,200 requests per second.”

Think time Think time is a deliberate pause inserted between requests in a test script to simulate the realistic behaviour of a human user, who pauses to read or interact with the page before making the next request. Example: “We added a two-second think time between each step to make the scenario more realistic.”

Percentile (p95, p99) Percentile values describe the distribution of response times across all requests. The p95 value, for example, means that 95% of requests completed within that time. These are more meaningful than averages because they reveal tail latency. Example: “Our p99 latency was 780ms under peak load, which is within our acceptable threshold.”

Smoke test In the context of k6, a smoke test is a brief test run with minimal load — typically one or two virtual users — used to verify that the test script is working correctly before running heavier scenarios. Example: “Always run a smoke test before a full load test to catch script errors early.”

Common Scenarios Where This Language Is Used

In a sprint planning meeting: Performance tests are often planned as part of a sprint. You might say: “I’ll write a k6 scenario for the checkout flow this sprint and run a baseline test before we merge the new payment integration.”

In a test results review: After a test run, you share findings with the team. Structure your report around: what was tested, what load was applied, what the results showed, and what the recommended action is.

When raising a performance concern: If results reveal a problem, you need to communicate it clearly and without alarm. “The p99 latency on the /api/products endpoint climbs to 3.4 seconds at 300 VUs, which is three times our SLO target. I recommend we investigate the database query before the next release.”

Useful Phrases for k6 Load Testing Discussions

• “I’ve written a test scenario that simulates the user journey from login through checkout.”
• “The ramp-up period is two minutes, followed by a ten-minute steady state.”
• “Results show the system starts degrading above 400 concurrent virtual users.”
• “We’re seeing a high error rate at peak load — most errors are 503s from the upstream service.”
• “The p95 latency is acceptable, but the p99 is a concern for our highest-traffic users.”
• “I ran the smoke test and the script is working as expected — we’re ready for the full run.”
• “Can we schedule the load test for off-peak hours to avoid impacting production?”
• “The threshold was breached on the error rate metric, so the test failed automatically.”
• “I’ll share the HTML report — you can drill into each metric from there.”
• “We should establish a baseline before the refactor so we can compare results.”

Reading and Presenting k6 Results

k6 outputs a rich set of metrics. When presenting results, avoid reading out every number. Instead, highlight the most relevant figures for your audience:

For a technical audience: focus on p95/p99 latency, error rate, and where in the ramp-up degradation began. For a non-technical audience: translate numbers into impact — “At our expected peak of 300 users, the average checkout takes 1.8 seconds, which is within our target.”

When writing a results summary, structure it as follows: test objective, test configuration (VUs, duration, scenario), key findings, and recommendations. Use a table for the headline metrics to make comparison easy.

Describing Test Scenarios in English

A test scenario describes the sequence of HTTP requests a virtual user makes. When writing documentation for a test, be specific about what user behaviour you are modelling.

“This scenario simulates an authenticated user browsing the product catalogue, adding three items to their basket, and completing a purchase. The scenario includes a two-second think time between each step and uses parameterised credentials from a CSV file.”

Avoid vague descriptions like “this tests the API.” Instead, specify which endpoints, what payload, and what user behaviour is being represented.

Practice Suggestion

Write a brief test plan in English for a k6 load test of a fictional e-commerce site. Specify the scenario (which user journey), the load profile (how many VUs, ramp-up time, duration), the success criteria (what latency and error rate thresholds are acceptable), and what you will do if the test fails. Keep it to one page and focus on clarity over completeness.