Performance Testing Techniques

1 The Hook

An Auckland government agency launches a new digital service. Load testing was run against the test environment — 2 vCPUs, 4 GB RAM. The test passed: 200 concurrent users handled fine.

The production environment is 8 vCPUs, 16 GB RAM. On go-live day, 850 users hit the service simultaneously at 9am. The service falls over at 300 users.

The test environment was under-spec'd compared to production, and the test assumed linear scaling. It didn't scale linearly. Database connection pools, caching warm-up, and thread management all behave differently at higher loads. The test told you nothing useful about production behaviour — it was guessing dressed up as evidence.

2 The Rule

3 The Analogy

4 Watch Me Do It

A k6 script for an NZ government portal login under combined load and stress conditions:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },  // Ramp up to 100 users
    { duration: '5m', target: 100 },  // Hold at 100 users (load test)
    { duration: '2m', target: 500 },  // Ramp to 500 users (stress test begins)
    { duration: '3m', target: 500 },  // Hold at stress level
    { duration: '2m', target: 0 },    // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95th percentile under 500ms
    http_req_failed: ['rate<0.01'],    // Error rate under 1%
  },
};

export default function () {
  const response = http.post('https://test.service.govt.nz/api/auth/login',
    JSON.stringify({ username: 'test-user', password: 'Test1234!' }),
    { headers: { 'Content-Type': 'application/json' } }
  );
  check(response, { 'login successful': (r) => r.status === 200 });
  sleep(1);
}

Reading the results:

• p95 response time — 95% of requests completed within this time. If p95 > 500ms at 100 users, you have a problem before stress even starts.
• Error rate — any error rate above 1% under normal load is a go/no-go blocker. At stress load, track when it first exceeds 1%.
• Throughput (req/s) — does it plateau or drop as you add users? A plateau means you've hit a ceiling. A drop means the system is struggling.
• Breaking point — the user count at which error rate spikes. This is your capacity ceiling — document it, don't hide it.

5 When to Use Each Type

6 Common Mistakes

7 Industry Reality

8 When to Use It — and When Not To

◆ What I would do

Professional judgment — when to reach for performance testing, when to skip it, and what to watch for.

9 Best Practices

10 Common Misconceptions

11 Now You Try

12 Self-Check

Click each question to reveal the answer.

13 ISTQB Mapping

15 Performance Test Types Deep-Dive

Each performance test type targets a different failure mode. Understanding the nuance between them lets you specify the right test — and defend the choice to stakeholders who think "load testing" covers everything.

Load Testing

Validates the system handles the expected number of concurrent users within agreed performance thresholds. This is your baseline — run it first, before anything else. If the system fails load testing, there is no point running stress or soak.

Stress Testing

Deliberately exceeds expected load to find the breaking point — the user count or transaction rate at which the system first fails or degrades unacceptably. The goal is not to make the system fail for fun; it is to know the failure mode before production discovers it.

Spike Testing

Simulates a sudden, sharp traffic surge — not a gradual ramp, but a near-instantaneous jump from normal to peak and back. The key metric is not just whether the system survives the spike, but how quickly it recovers to normal response times after the spike subsides.

Soak / Endurance Testing

Runs the system at moderate sustained load for 12–24+ hours to expose problems that only emerge over time: memory leaks, connection pool exhaustion, disk filling, gradual thread accumulation. A system can pass a 30-minute load test and still fail catastrophically after 8 hours in production.

Volume Testing

Tests the system's behaviour under large data sets, independent of concurrent users. The question is not "how many people are using it" but "how does it perform when the database holds millions of records and the batch job must process all of them?"

16 k6 Quick Start

k6 is the industry-standard open-source performance testing tool for APIs and web services. Scripts are written in JavaScript, version-controlled alongside your codebase, and CI-ready. Here is a complete script for a NZ KiwiSaver balance API covering ramp-up, sustained load, spike, and ramp-down — with thresholds that act as automated pass/fail gates.

import http from 'k6/http';
import { check, sleep } from 'k6';

// Performance thresholds — the test FAILS if these are breached
export const options = {
  stages: [
    { duration: '2m', target: 50  },  // Ramp up to 50 virtual users
    { duration: '5m', target: 50  },  // Hold at 50 — normal load window
    { duration: '1m', target: 200 },  // Spike to 200 users (end-of-financial-year burst)
    { duration: '5m', target: 200 },  // Hold at spike level
    { duration: '2m', target: 0   },  // Ramp down — verify graceful recovery
  ],
  thresholds: {
    // 95th-percentile response time must stay under 2 seconds
    http_req_duration: ['p(95)<2000'],
    // Error rate must stay under 1%
    http_req_failed: ['rate<0.01'],
  },
};

export default function () {
  const params = {
    headers: {
      'Content-Type': 'application/json',
      // Use a real member token in your .env — never hardcode production credentials
      'Authorization': 'Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.test-member-token',
    },
  };

  const response = http.get(
    'https://test-api.kiwisaver-provider.co.nz/v2/members/balance',
    params
  );

  // Assertions — failures increment the http_req_failed metric
  check(response, {
    'status is 200':           (r) => r.status === 200,
    'response under 2 seconds': (r) => r.timings.duration < 2000,
    'balance present in body':  (r) => JSON.parse(r.body).balance !== undefined,
  });

  sleep(1); // 1-second think time between requests (simulates real user pacing)
}

Reading the output:

• http_req_duration p(95) — if this exceeds 2000ms at any stage, the threshold fails and k6 exits with a non-zero code (CI pipeline fails automatically).
• http_req_failed rate — any value above 0.01 (1%) is a threshold breach. Monitor this at the spike stage — it is often the first metric to move.
• Spike recovery — watch p95 in the final ramp-down stage. If it stays elevated after load drops, the system is not recovering cleanly (connection pool starvation or GC pressure).

17 Performance Targets for NZ Systems

Generic targets like "under 3 seconds" are hard to defend. These reference targets are grounded in WCAG 2.1 timing guidance and NZ Government Digital Service Standards, giving you a starting point for negotiating acceptance criteria with product owners and stakeholders.

14 Next Steps