k6

What is a k6 threshold, and why does it matter more than just reading the output report?

What they’re really testing: Whether you understand that k6 is a quality gate, not just a metrics collector — and that a test with no thresholds provides information but no enforcement.

Strong answer covers: Thresholds define pass/fail criteria (e.g. p95 < 300ms, error_rate < 0.01) and cause k6 to return a non-zero exit code when breached; that exit code is what lets a CI pipeline like GitHub Actions or Azure DevOps block a deployment; NZ context — a team at a government agency like Revenue NZ could set a threshold tied to their SLA commitments before each tax-season release.

When would you choose k6 over JMeter for a performance testing project?

What they’re really testing: Whether you can make a reasoned tool decision rather than defaulting to whichever tool you learned first — and whether you understand the trade-offs in team capability, test complexity, and CI integration.

Strong answer covers: k6 wins when the team writes JavaScript, tests need to live in the same repo as the code and be PR-reviewed, and CI integration with exit codes matters; JMeter wins when non-technical stakeholders need to author tests via GUI or when complex browser-level scenarios are required; a NZ-specific signal — e.g. a Wellington SaaS startup where devs already use Node would get more value from k6 than retooling for JMeter’s XML test plans.

You’re a QA engineer at an Auckland fintech and the business wants a load test before launching open banking APIs to NZ consumers. How would you design the k6 test suite?

What they’re really testing: Whether you can translate a business risk into a test strategy — choosing the right load profile, identifying which endpoints matter, and thinking about data privacy constraints in a regulated environment.

Strong answer covers: Mapping the highest-risk journeys (consent flow, account data retrieval, payment initiation); choosing a ramp-up load profile that reflects real adoption curves rather than an arbitrary spike; using anonymised or synthetic test accounts to avoid touching real customer data under the Privacy Act 2020; setting thresholds aligned to the open banking API response-time SLA; and running against a staging environment that mirrors production infrastructure.

Your k6 tests pass locally but the p95 latency threshold fails consistently in CI. How do you investigate?

What they’re really testing: Whether you can systematically diagnose environmental differences rather than dismissing CI results as noise or blindly tuning thresholds upward.

Strong answer covers: Checking whether the CI runner is CPU/network constrained compared to your local machine (k6 is Go-based and CPU-sensitive at high VU counts); verifying the target environment is the same (staging vs localhost); inspecting k6’s --out metrics to see if the latency spike is uniform or only affects specific endpoints; considering whether the CI environment shares resources with other jobs; and using k6 run --vus 1 as a baseline to separate network latency from load-induced degradation.

How would you structure a k6 test suite for a large NZ e-commerce platform so it stays maintainable as the API grows?

What they’re really testing: Whether you think about test architecture and long-term maintainability, not just writing a single script that works once.

Strong answer covers: Separating shared helpers (auth, data setup) into reusable modules imported across test files; grouping scripts by journey or service boundary rather than one monolithic file; using k6 scenarios to define different load profiles (smoke, load, soak, spike) without duplicating business logic; storing threshold definitions in a shared config so they can be tightened centrally; and treating the k6 suite as production code — reviewed in PRs, linted, and kept in the same repo as the service it tests, which is standard practice at NZ-scale platforms like Trademe or Pushpay.