An article titled From zero load testing experience to running tests with k6: A 4th-year engineer's journey (Zenn) recently drew significant attention. Recounting the experience of "taking charge of tool selection, test design, execution, and evaluation with k6 as a near-beginner preparing for a production release," it demonstrates that load testing is no longer reserved for a handful of specialists; with modern tools, everyday engineers can run it successfully.
On the other hand, incidents where "a system goes live without verifying whether it can withstand expected traffic, only to crash on the first day of a promotional campaign," remain endless in custom development. When supporting system development for clients, we view this not as a question of "whether to test," but rather as a contractual imperative to define "which target metrics, under which scenarios, and to what extent we guarantee before delivery." Connecting with our past discussions on automated functional quality verification in Playwright AI QA Automation for Clients (GH Media), production performance pitfalls in Performance Audits Inspired by Pinterest CPU Zombies (GH Media), and tail latency countermeasures in SRE Tuning for P99 Latency Improvement (GH Media), this article outlines how to structure "Load Testing & Performance Assurance" within client engagements.
Why load testing with k6 "now"?
| Dimension | Unverified performance (conventional) | Performance guaranteed with k6 (2026) |
|---|---|---|
| Test specification | Dependent on dedicated tools / GUI | Written in JavaScript |
| CI integration | Manual execution | Integrated into pipelines |
| Target metrics | Ambiguous | Documented via SLOs |
| Reproducibility | Dependent on individual intuition | Reproducible via code |
| Release decision | Gut feeling | Automated pass/fail based on thresholds |
| Handover | No test assets | Scenarios + runbooks |
In other words, the widespread adoption of code-based load testing tools like k6 has made it possible for custom development to standardize a workflow of "measuring performance, setting targets, and evaluating pass/fail." This allows us to guarantee that the system "will not crash" as part of the core deliverables.
Three structural changes beneficial to custom development projects
Dynamic 1: From "releasing on intuition" to "pass/fail evaluated by SLOs"
Releasing based on "it'll probably be fine" invites disaster. In client projects, we define target response times, error rates, and concurrent connections as SLOs, and generate automated pass/fail results via k6 thresholds, thereby making release decisions objective.
Dynamic 2: From "one-off tests" to "continuous CI integration"
Testing only at release time overlooks performance degradation introduced by ongoing code updates. In custom development, we integrate load testing into CI/CD to provide a mechanism that detects performance regressions early.
Dynamic 3: From "neglected bottlenecks" to "root-cause identification and remediation"
Simply identifying poor metrics does not fix problems. In client engagements, leveraging insights from Performance Audits Inspired by Pinterest CPU Zombies (GH Media), we pinpoint bottlenecks by combining k6 with APM and profilers, and provide end-to-end support through remediation.
5 phases of "load testing and performance assurance" for client projects
Phase 1: Target & assumption design (1 week)
- Clarify expected peaks (campaigns / beginning of month / concurrent users)
- Define SLOs (p95 response time / error rate / throughput)
- Select test scenarios (login / purchase / search)
- Establish test environment strategy (production-equivalent vs. scaled-down)
Phase 2: Scenario implementation (1–2 weeks)
- Implement user scenarios in JavaScript using k6
- Prepare test data (test users / products)
- Design workload models (ramp-up / spike / sustained)
- Define pass/fail criteria using thresholds
Phase 3: Test execution & analysis (1–2 weeks)
- Execute stepped load tests (baseline -> peak -> stress limit)
- Identify bottlenecks using APM and system metrics
- Check DB, connection pools, N+1 queries, and garbage collection
- Identify saturation limits and scaling characteristics
Phase 4: Remediation & re-testing (2–3 weeks)
- Remediate bottlenecks (queries / caching / configurations)
- Confirm SLO attainment through re-testing
- Produce release assessment report
Phase 5: Ongoing operations (continuous)
- Integrate load testing into CI
- Monitor for performance regressions
- Conduct periodic pre-peak testing
Standard technology stack set for custom development
| Layer | Recommended technology | Alternative |
|---|---|---|
| Load generation | k6 | Gatling / Locust / JMeter |
| Test specification | JavaScript scenarios | TypeScript |
| CI integration | GitHub Actions | GitLab CI |
| Visualization | Grafana + k6 output | Datadog |
| APM | OpenTelemetry | New Relic / Datadog |
| Environment | Production-equivalent staging | Reproduced via containers |
Which projects need this and which do not
| Projects requiring this | Low-priority projects |
|---|---|
| Instant surges from campaigns, reservations, or applications | Internal use by a very small group |
| Significant opportunity loss (e-commerce, bookings, ticketing) | Extremely minimal traffic |
| Initial release with no historical track record | Sufficient historical performance data already exists |
| SLA / performance guaranteed contractually | Agreed on a best-effort basis |
| High release frequency with fears of regression | Static sites that are rarely updated |
Six clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Performance targets | SLOs (response / error rate / concurrency) | Agreement on projected peaks |
| Test scope | Target scenarios / environments | Feasibility of production testing |
| Pass/fail criteria | Thresholds and evaluation methods | Handling of unmet benchmarks |
| Remediation scope | Tuning scope | Boundary for additional development |
| Handover | Scenarios / reports / runbooks | In-house sustainability |
| Continuous testing | CI integration / periodic testing | Operating costs |
Client-side ROI estimate (e-commerce site / assuming campaign launch day)
| Item | Existing (unverified release) | Load testing & performance assurance | Difference |
|---|---|---|---|
| Day-one crash probability | High | Dramatically reduced | Avoided opportunity loss |
| Projected opportunity loss | Millions of yen scale | Avoided through prevention | Risk reduced |
| Incident response effort | Strained by emergency response | Resolved proactively | Overtime and brand damage avoided |
| Scaling decisions | Excessive or inadequate | Based on actual measurements | Infrastructure cost optimization |
| Annual benefit | — | — | Major outage avoided + curb on infrastructure over-provisioning |
In almost all cases, the cost of testing and remediation is amply justified when weighed against the revenue and trust lost in a single day-one outage.
Five common pitfalls
Pitfall 1: Testing in an environment different from production
Results from scaled-down environments are unreliable. Measure using a production-equivalent architecture.
Pitfall 2: Looking only at averages
Tail latencies at p95 and p99 dictate the actual user experience. Evaluate using percentiles.
Pitfall 3: The load generator becoming the bottleneck
Insufficient test machine capacity can cap load prematurely. Ensure distributed execution and adequate load generation capacity.
Pitfall 4: Stopping after generating numbers
You cannot fix issues without root-cause identification. Isolate bottlenecks by pairing tests with APM.
Pitfall 5: Treating testing as a one-time event
Performance degrades with ongoing modifications. Integrate into CI for continuous regression detection.
90-day action plan
| Week | Action |
|---|---|
| Week 1 | Define SLOs + select test scenarios |
| Week 2〜3 | Implement k6 scenarios + prepare test data |
| Week 4〜5 | Execute stepped load tests + pinpoint bottlenecks |
| Week 6〜9 | Remediate + re-test to achieve SLOs |
| Week 10〜13 | Integrate into CI + begin periodic testing operations |
Summary — From "releasing on intuition" to "delivering with guaranteed performance"
With the spread of code-based load testing tools like k6, performance verification has become something everyday engineers can manage. When supporting client system development, defining goals via SLOs, reproducing them through scenarios, evaluating pass/fail via thresholds, and maintaining continuous detection in CI represents a pragmatic way to deliver release confidence as a tangible deliverable.
The effort required for load test design and performance assurance varies considerably depending on system scale, projected traffic spikes, and test environment parameters. Because we provide tailored estimates after reviewing your specific setup, please feel free to reach out via our contact form even if you are simply at the stage of thinking: "We cannot afford to crash on campaign launch day," "We want contractually guaranteed performance," or "We are worried about degradation after every release."
Sources
- From zero load testing experience to running tests with k6: A 4th-year engineer's journey (Zenn 2026-06-01)
- Playwright AI QA Automation for Clients (GH Media)
- Performance Audits Inspired by Pinterest CPU Zombies (GH Media)
- SRE Tuning for P99 Latency Improvement (GH Media)
- Core Web Vitals Guide (GH Media)
