Testing Perf

Performance & Load Testing Patterns

Focused skill for performance testing, load testing, and pytest execution optimization. Covers k6, Locust, pytest-xdist parallel execution, custom plugins, and test type classification.

Quick Reference

k6 Quick Start

Set up a load test with thresholds and staged ramp-up:

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

export const options = {
  stages: [
    { duration: '30s', target: 20 },  // Ramp up
    { duration: '1m', target: 20 },   // Steady state
    { duration: '30s', target: 0 },   // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95th percentile under 500ms
    http_req_failed: ['rate<0.01'],    // Less than 1% error rate
  },
};

export default function () {
  const res = http.get('http://localhost:8000/api/health');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

Run: k6 run --out json=results.json tests/load/api.js

k6 v1.0+ (May 2025) — what changed

• Native TypeScript: k6 run tests/load/api.ts — no compilation step needed.
• Auto extension provisioning: k6 run pulls required extensions automatically; manual xk6 build is superseded for most workflows.
• Browser module import: import browser from 'k6/browser' — the old `k6/experimental/browser` path was removed in v0.52+. Any generated code using /experimental/ will fail.
• OTLP output built in: k6 run --out experimental-opentelemetry=... — stream results straight to your tracing backend.

import http from 'k6/http'
import browser from 'k6/browser'
import { check } from 'k6'

export const options = { vus: 5, duration: '30s' }

export default async function () {
  const page = await browser.newPage()
  await page.goto('https://example.com')
  check(page, { 'title present': async p => (await p.title()).length > 0 })
  await page.close()
}

Performance Test Types

pytest Parallel Execution

Speed up test suites with pytest-xdist:

# pyproject.toml
[tool.pytest.ini_options]
addopts = ["-n", "auto", "--dist", "loadscope"]
markers = [
    "slow: marks tests as slow",
    "smoke: critical path tests for CI/CD",
]

# Run with parallel workers and coverage
pytest -n auto --dist loadscope --cov=app --cov-report=term-missing --maxfail=3

# CI fast path — skip slow tests
pytest -m "not slow" -n auto

# Debug mode — single worker
pytest -n 0 -x --tb=long

Worker Database Isolation

When running parallel tests with databases, isolate per worker:

@pytest.fixture(scope="session")
def db_engine(worker_id):
    db_name = f"test_db_{worker_id}" if worker_id != "master" else "test_db"
    engine = create_engine(f"postgresql://localhost/{db_name}")
    yield engine
    engine.dispose()

Key Thresholds

Decision Guide

Related Skills

• ork:testing-unit — Unit testing patterns, pytest fixtures
• ork:testing-e2e — End-to-end performance testing with Playwright
• ork:performance — Core Web Vitals and optimization patterns

Performance Testing Checklist

Test Planning

• [ ] Define performance goals
• [ ] Identify critical paths
• [ ] Determine test scenarios
• [ ] Set baseline metrics

Test Setup

• [ ] Production-like environment
• [ ] Realistic test data
• [ ] Proper warm-up period
• [ ] Isolated test environment

Metrics

• [ ] Response time (p50, p95, p99)
• [ ] Throughput (requests/sec)
• [ ] Error rate
• [ ] Resource utilization

Load Patterns

• [ ] Steady state
• [ ] Ramp up
• [ ] Spike testing
• [ ] Soak testing

Analysis

• [ ] Identify bottlenecks
• [ ] Compare to baseline
• [ ] Document findings
• [ ] Create action items

Pytest Production Checklist

Configuration

• [ ] pyproject.toml has all custom markers defined
• [ ] conftest.py at project root for shared fixtures
• [ ] pytest-asyncio mode configured (mode = "auto")
• [ ] Coverage thresholds set (--cov-fail-under=80)

Markers

• [ ] All tests have appropriate markers (smoke, integration, db, slow)
• [ ] Marker filter expressions tested (pytest -m "not slow")
• [ ] CI pipeline uses marker filtering

Parallel Execution

• [ ] pytest-xdist configured (-n auto --dist loadscope)
• [ ] Worker isolation verified (no shared state)
• [ ] Database fixtures use worker_id for isolation
• [ ] Redis/external services use unique namespaces per worker

Fixtures

• [ ] Expensive fixtures use scope="session" or scope="module"
• [ ] Factory fixtures for complex object creation
• [ ] All fixtures have proper cleanup (yield + teardown)
• [ ] No global state mutations in fixtures

Performance

• [ ] Slow tests marked with @pytest.mark.slow
• [ ] No unnecessary time.sleep() (use mocking)
• [ ] Large datasets use lazy loading
• [ ] Timing reports enabled for slow test detection

CI/CD

• [ ] Tests run in parallel in CI
• [ ] Coverage reports uploaded
• [ ] Test results in JUnit XML format
• [ ] Flaky test detection enabled

Code Quality

• [ ] No skipped tests without reasons (@pytest.mark.skip(reason="..."))
• [ ] xfail tests have documented reasons
• [ ] Parametrized tests have descriptive IDs
• [ ] Test names follow convention (test_<what>_<condition>_<expected>)

Custom Pytest Plugins

Plugin Types

Local Plugins (conftest.py)

For project-specific functionality. Auto-loaded from any conftest.py.

# conftest.py
import pytest

def pytest_configure(config):
    """Run once at pytest startup."""
    config.addinivalue_line(
        "markers", "smoke: critical path tests"
    )

def pytest_collection_modifyitems(config, items):
    """Reorder tests: smoke first, slow last."""
    items.sort(key=lambda x: (
        0 if x.get_closest_marker("smoke") else
        2 if x.get_closest_marker("slow") else 1
    ))

Installable Plugins

For reusable functionality across projects.

# pytest_timing_plugin.py
import pytest
from datetime import datetime

class TimingPlugin:
    def __init__(self, threshold: float = 1.0):
        self.threshold = threshold
        self.slow_tests = []

    @pytest.hookimpl(hookwrapper=True)
    def pytest_runtest_call(self, item):
        start = datetime.now()
        yield
        duration = (datetime.now() - start).total_seconds()
        if duration > self.threshold:
            self.slow_tests.append((item.nodeid, duration))

    def pytest_terminal_summary(self, terminalreporter):
        if self.slow_tests:
            terminalreporter.write_sep("=", "Slow Tests Report")
            for nodeid, duration in sorted(self.slow_tests, key=lambda x: -x[1]):
                terminalreporter.write_line(f"  {duration:.2f}s - {nodeid}")

def pytest_configure(config):
    config.pluginmanager.register(TimingPlugin(threshold=1.0))

Hook Reference

Collection Hooks

def pytest_collection_modifyitems(config, items):
    """Modify collected tests."""

def pytest_generate_tests(metafunc):
    """Generate parametrized tests dynamically."""

Execution Hooks

@pytest.hookimpl(tryfirst=True, hookwrapper=True)
def pytest_runtest_makereport(item, call):
    """Access test results."""
    outcome = yield
    report = outcome.get_result()
    if report.when == "call" and report.failed:
        # Handle failures
        pass

Setup/Teardown Hooks

def pytest_configure(config):
    """Startup hook."""

def pytest_unconfigure(config):
    """Shutdown hook."""

def pytest_sessionstart(session):
    """Session start."""

def pytest_sessionfinish(session, exitstatus):
    """Session end."""

Publishing a Plugin

# pyproject.toml
[project]
name = "pytest-my-plugin"
version = "1.0.0"

[project.entry-points.pytest11]
my_plugin = "pytest_my_plugin"

k6 Load Testing Patterns

Common patterns for effective performance testing with k6.

Implementation

Staged Ramp-Up Pattern

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

export const options = {
  stages: [
    { duration: '1m', target: 50 },   // Ramp up to 50 users
    { duration: '3m', target: 50 },   // Stay at 50 users
    { duration: '1m', target: 100 },  // Ramp to 100 users
    { duration: '3m', target: 100 },  // Stay at 100 users
    { duration: '2m', target: 0 },    // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    http_req_failed: ['rate<0.01'],
    checks: ['rate>0.99'],
  },
};

export default function () {
  const res = http.get('http://localhost:8000/api/health');

  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
    'body contains status': (r) => r.body.includes('ok'),
  });

  sleep(Math.random() * 2 + 1); // 1-3 second think time
}

Authenticated Requests Pattern

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

export function setup() {
  const loginRes = http.post('http://localhost:8000/api/auth/login', {
    email: 'loadtest@example.com',
    password: 'testpassword',
  });

  return { token: loginRes.json('access_token') };
}

export default function (data) {
  const params = {
    headers: { Authorization: `Bearer ${data.token}` },
  };

  const res = http.get('http://localhost:8000/api/protected', params);
  check(res, { 'authenticated request ok': (r) => r.status === 200 });
}

Test Types Summary

Checklist

• [ ] Define realistic thresholds (p95, p99, error rate)
• [ ] Include proper ramp-up period (avoid cold start)
• [ ] Add think time between requests (sleep)
• [ ] Use checks for functional validation
• [ ] Externalize configuration (stages, VUs)
• [ ] Run smoke test before full load test

pytest-xdist Parallel Execution

Distribution Modes

loadscope (Recommended Default)

Groups tests by module for test functions and by class for test methods. Ideal when fixtures are expensive.

pytest -n auto --dist loadscope

loadfile

Groups tests by file. Good balance of parallelism and fixture sharing.

pytest -n auto --dist loadfile

loadgroup

Tests grouped by @pytest.mark.xdist_group(name="group1") marker.

@pytest.mark.xdist_group(name="database")
def test_create_user():
    pass

@pytest.mark.xdist_group(name="database")
def test_delete_user():
    pass

load

Round-robin distribution for maximum parallelism. Best when tests are truly independent.

pytest -n auto --dist load

Worker Isolation

Each worker is completely isolated:

• Global state isn't shared
• Environment variables are independent
• Temp files/databases must be unique per worker

@pytest.fixture(scope="session")
def db_engine(worker_id):
    """Create isolated database per worker."""
    if worker_id == "master":
        db_name = "test_db"  # Not running in parallel
    else:
        db_name = f"test_db_{worker_id}"  # gw0, gw1, etc.

    engine = create_engine(f"postgresql://localhost/{db_name}")
    yield engine
    engine.dispose()

Resource Allocation

# Auto-detect cores (recommended)
pytest -n auto

# Specific count
pytest -n 4

# Use logical CPUs
pytest -n logical

Warning: Over-provisioning (e.g., -n 20 on 4 cores) increases overhead.

CI/CD Configuration

# GitHub Actions
- name: Run tests in parallel
  run: pytest -n auto --dist loadscope -v
  env:
    PYTEST_XDIST_AUTO_NUM_WORKERS: 4  # Override auto detection

Limitations

• -s/--capture=no doesn't work with xdist
• Some fixtures may need refactoring for parallelism
• Database tests need worker-isolated databases

Rule Categories

1. Load Testing (perf) — MEDIUM — 3 rules

Load and stress testing patterns for API performance validation.

• perf-k6.md — k6 load test stages, p95 thresholds, check() assertions
• perf-locust.md — Locust HttpUser tasks, on_start authentication, wait_time simulation
• perf-types.md — Load/stress/spike/soak test classification, traffic profiles, CI integration

2. Test Execution (pytest) — HIGH — 3 rules

Pytest infrastructure for fast, organized test execution.

• execution.md — Coverage reporting, --maxfail CI feedback, --lf iteration, threshold enforcement
• pytest-execution.md — Custom markers, pytest-xdist parallel execution, selective test runs
• pytest-plugins.md — Factory fixtures, pytest hooks, pytest-asyncio auto mode

Coverage Reporting

Track and enforce test coverage to identify untested critical paths.

Incorrect — running tests without coverage:

pytest tests/  # No coverage data — can't identify gaps
npm run test   # No --coverage flag — blind to untested code

Correct — coverage with gap analysis:

# Python: pytest-cov with missing line report
poetry run pytest tests/unit/ \
  --cov=app \
  --cov-report=term-missing \
  --cov-report=html:htmlcov

# JavaScript: Jest with coverage
npm run test -- --coverage --coverageReporters=text --coverageReporters=lcov

Coverage report format:

# Test Results Report

## Summary
| Suite | Total | Passed | Failed | Coverage |
|-------|-------|--------|--------|----------|
| Backend | 150 | 148 | 2 | 87% |
| Frontend | 95 | 95 | 0 | 82% |

Coverage targets:

Key rules:

• Use --cov-report=term-missing to see exactly which lines are uncovered
• Set minimum coverage thresholds in CI to prevent regression
• Focus on covering critical paths (auth, payments) before chasing overall percentage
• HTML coverage reports (htmlcov/) help visualize gap areas during development
• Coverage numbers alone do not indicate test quality — pair with mutation testing for confidence

---

Parallel Test Execution

Run tests in parallel with smart failure handling and scope-based execution.

Incorrect — running everything sequentially with full output:

# Runs all tests sequentially, floods output, no failure control
pytest tests/ -v

Correct — scoped execution with failure limits and coverage:

# Backend with coverage and failure limit
cd backend
poetry run pytest tests/unit/ -v --tb=short \
  --cov=app --cov-report=term-missing \
  --maxfail=3

# Frontend with coverage
cd frontend
npm run test -- --coverage

# Specific test (fast feedback)
poetry run pytest tests/unit/ -k "test_name" -v

Test scope options:

Failure analysis — launch 3 parallel analyzers on failure: 1. Backend Failure Analysis — root cause, fix suggestions 2. Frontend Failure Analysis — component issues, mock problems 3. Coverage Gap Analysis — low coverage areas

Key pytest options:

Key rules:

• Use --maxfail=3 in CI for fast feedback without overwhelming output
• Use --tb=short by default — --tb=long only when debugging specific failures
• Run --lf (last-failed) during development for rapid iteration
• Always include --cov in CI runs to track coverage trends
• Use --watch mode during frontend development for continuous feedback

k6 Load Testing

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

export const options = {
  stages: [
    { duration: '30s', target: 20 },  // Ramp up
    { duration: '1m', target: 20 },   // Steady
    { duration: '30s', target: 0 },   // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95% under 500ms
    http_req_failed: ['rate<0.01'],    // <1% errors
  },
};

export default function () {
  const res = http.get('http://localhost:8500/api/health');

  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });

  sleep(1);
}

Custom Metrics

import { Trend, Counter, Rate } from 'k6/metrics';

const responseTime = new Trend('response_time');
const errors = new Counter('errors');
const successRate = new Rate('success_rate');

CI Integration

- name: Run k6 load test
  run: k6 run --out json=results.json tests/load/api.js

Key Decisions

Incorrect — No thresholds, tests pass even with poor performance:

export const options = {
  stages: [{ duration: '1m', target: 20 }]
  // Missing: thresholds for response time and errors
};

Correct — Thresholds enforce performance requirements:

export const options = {
  stages: [{ duration: '1m', target: 20 }],
  thresholds: {
    http_req_duration: ['p(95)<500'],
    http_req_failed: ['rate<0.01']
  }
};

Locust Load Testing

from locust import HttpUser, task, between

class APIUser(HttpUser):
    wait_time = between(1, 3)

    @task(3)
    def get_analyses(self):
        self.client.get("/api/analyses")

    @task(1)
    def create_analysis(self):
        self.client.post(
            "/api/analyses",
            json={"url": "https://example.com"}
        )

    def on_start(self):
        """Login before tasks."""
        self.client.post("/api/auth/login", json={
            "email": "test@example.com",
            "password": "password"
        })

Key Decisions

Incorrect — No authentication flow, requests fail:

class APIUser(HttpUser):
    @task
    def get_analyses(self):
        self.client.get("/api/analyses")  # 401 Unauthorized

Correct — Login in on_start before tasks:

class APIUser(HttpUser):
    def on_start(self):
        self.client.post("/api/auth/login", json={
            "email": "test@example.com", "password": "password"
        })

    @task
    def get_analyses(self):
        self.client.get("/api/analyses")  # Authenticated

Performance Test Types

Load Test (Normal expected load)

export const options = {
  vus: 50,
  duration: '5m',
};

Stress Test (Find breaking point)

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '2m', target: 200 },
    { duration: '2m', target: 300 },
    { duration: '2m', target: 400 },
  ],
};

Spike Test (Sudden traffic surge)

export const options = {
  stages: [
    { duration: '10s', target: 10 },
    { duration: '1s', target: 1000 },  // Spike!
    { duration: '3m', target: 1000 },
    { duration: '10s', target: 10 },
  ],
};

Soak Test (Sustained load for memory leaks)

export const options = {
  vus: 50,
  duration: '4h',
};

Common Mistakes

• Testing against production without protection
• No warmup period
• Unrealistic load profiles
• Missing error rate thresholds

Incorrect — No warmup, sudden load spike:

export const options = {
  vus: 100,
  duration: '5m'
  // No ramp-up, cold start skews results
};

Correct — Gradual ramp-up with warmup period:

export const options = {
  stages: [
    { duration: '30s', target: 20 },   // Warmup
    { duration: '1m', target: 100 },   // Ramp up
    { duration: '3m', target: 100 },   // Steady load
    { duration: '30s', target: 0 }     // Ramp down
  ]
};

Custom Pytest Markers

Configuration

# pyproject.toml
[tool.pytest.ini_options]
markers = [
    "slow: marks tests as slow (deselect with '-m \"not slow\"')",
    "integration: marks tests requiring external services",
    "smoke: critical path tests for CI/CD",
]

Usage

import pytest

@pytest.mark.slow
def test_complex_analysis():
    result = perform_complex_analysis(large_dataset)
    assert result.is_valid

# Run: pytest -m "not slow"  # Skip slow tests
# Run: pytest -m smoke       # Only smoke tests

Key Decisions

Incorrect — Using markers without registering them:

@pytest.mark.slow
def test_complex():
    pass
# Pytest warns: PytestUnknownMarkWarning

Correct — Register markers in pyproject.toml:

[tool.pytest.ini_options]
markers = [
    "slow: marks tests as slow",
    "integration: marks tests requiring external services"
]

---

Parallel Execution with pytest-xdist

Configuration

[tool.pytest.ini_options]
addopts = ["-n", "auto", "--dist", "loadscope"]

Worker Database Isolation

@pytest.fixture(scope="session")
def db_engine(worker_id):
    """Isolate database per worker."""
    db_name = "test_db" if worker_id == "master" else f"test_db_{worker_id}"
    engine = create_engine(f"postgresql://localhost/{db_name}")
    yield engine

Distribution Modes

Key Decisions

Incorrect — Shared database across workers causes conflicts:

@pytest.fixture(scope="session")
def db_engine():
    return create_engine("postgresql://localhost/test_db")
    # Workers overwrite each other's data

Correct — Isolated database per worker:

@pytest.fixture(scope="session")
def db_engine(worker_id):
    db_name = f"test_db_{worker_id}" if worker_id != "master" else "test_db"
    return create_engine(f"postgresql://localhost/{db_name}")

Pytest Plugins and Hooks

Factory Fixtures

@pytest.fixture
def user_factory(db_session) -> Callable[..., User]:
    """Factory fixture for creating users."""
    created = []

    def _create(**kwargs) -> User:
        user = User(**{"email": f"u{len(created)}@test.com", **kwargs})
        db_session.add(user)
        created.append(user)
        return user

    yield _create
    for u in created:
        db_session.delete(u)

Anti-Patterns (FORBIDDEN)

# NEVER use expensive fixtures without session scope
@pytest.fixture  # WRONG - loads every test
def model():
    return load_ml_model()  # 5s each time!

# NEVER mutate global state
@pytest.fixture
def counter():
    global _counter
    _counter += 1  # WRONG - leaks between tests

# NEVER skip cleanup
@pytest.fixture
def temp_db():
    db = create_db()
    yield db
    # WRONG - missing db.drop()!

Key Decisions

Incorrect — Expensive fixture without session scope:

@pytest.fixture
def ml_model():
    return load_large_model()  # 5s, reloaded EVERY test

Correct — Session-scoped fixture for expensive setup:

@pytest.fixture(scope="session")
def ml_model():
    return load_large_model()  # 5s, loaded ONCE

Test Case Template

Your Task

Use this test case template to document a manual or automated test case. Fill in each section with the specifics of your test scenario, including preconditions, steps, and expected results.

Test Case ID: TC-[NUMBER]

Module/Feature: [Feature Name] Priority: [Critical / High / Medium / Low] Test Type: [Unit / Integration / E2E / Performance] Status: [Not Started / In Progress / Completed / Blocked]

---

Test Information

Created by: [Your Name] Created date: YYYY-MM-DD Last updated: YYYY-MM-DD Estimated time: [X minutes]

---

Objective

Brief description of what this test validates.

---

Preconditions

List all preconditions that must be met before executing this test:

• [ ] User account exists in test database
• [ ] Test environment is running
• [ ] Test data is seeded
• [ ] Required services are healthy

---

Test Data

---

Test Steps

Given (Initial Context)

Describe the initial state of the system:

• User is logged in as test@example.com
• Shopping cart is empty
• User has valid payment method on file

When (Action)

Describe the action being tested: 1. Navigate to product page /products/12345 2. Click "Add to Cart" button 3. Navigate to cart page /cart 4. Click "Checkout" button 5. Complete payment form 6. Click "Place Order" button

Then (Expected Result)

Describe the expected outcome:

• Order confirmation page is displayed
• Order number is shown in format ORD-XXXXXX
• Email confirmation is sent to test@example.com
• Inventory is decremented by 1 for product 12345
• Payment charge appears in Stripe dashboard
• Database shows order with status "completed"

---

Detailed Test Steps (Alternative Format)

---

Validation Checkpoints

Verify the following after test execution:

UI Validation:

• [ ] Success message displays: "Order placed successfully"
• [ ] Order number shown in correct format
• [ ] Order summary matches cart contents
• [ ] Payment confirmation appears

API Validation:

• [ ] POST /api/orders returns 201 status
• [ ] Response includes order ID, status, and total
• [ ] GET /api/orders/:id returns complete order details

Database Validation:

• [ ] Order record exists in orders table
• [ ] Order items exist in order_items table
• [ ] Inventory decremented in products table
• [ ] Payment record exists in payments table

Integration Validation:

• [ ] Email sent to user's email address
• [ ] Payment charge processed in Stripe
• [ ] Inventory service notified of stock change

---

Test Code (Automated)

import { test, expect } from '@playwright/test';

test('TC-001: User can complete checkout flow', async ({ page }) => {
  // Given: User is logged in
  await page.goto('/login');
  await page.fill('[data-testid="email"]', 'test@example.com');
  await page.fill('[data-testid="password"]', 'Test123!');
  await page.click('[data-testid="login-button"]');
  await expect(page).toHaveURL('/dashboard');

  // When: User adds item and checks out
  await page.goto('/products/12345');
  await page.click('[data-testid="add-to-cart"]');
  await expect(page.locator('[data-testid="success-message"]')).toBeVisible();

  await page.goto('/cart');
  await expect(page.locator('[data-testid="cart-item"]')).toHaveCount(1);

  await page.click('[data-testid="checkout-button"]');
  await page.fill('[data-testid="card-number"]', '4242424242424242');
  await page.fill('[data-testid="card-expiry"]', '12/25');
  await page.fill('[data-testid="card-cvc"]', '123');
  await page.click('[data-testid="submit-payment"]');

  // Then: Order confirmation is shown
  await expect(page.locator('[data-testid="order-confirmation"]')).toBeVisible();
  const orderNumber = await page.locator('[data-testid="order-number"]').textContent();
  expect(orderNumber).toMatch(/ORD-\d{6}/);

  // Verify database state
  const order = await db.orders.findOne({ order_number: orderNumber });
  expect(order).toBeTruthy();
  expect(order.status).toBe('completed');
  expect(order.user_email).toBe('test@example.com');
});

---

Edge Cases and Variations

List alternative scenarios and edge cases:

Variation 1: Out of Stock

• When: User tries to checkout with out-of-stock item
• Then: Error message shown, order not created

Variation 2: Payment Failure

• When: Payment gateway returns failure
• Then: Error displayed, order status = "payment_failed"

Variation 3: Invalid Coupon Code

• When: User enters expired coupon code
• Then: Coupon not applied, error message shown

Variation 4: Guest Checkout

• When: User not logged in
• Then: Can still checkout but must provide email

---

Dependencies

This test depends on:

• Product catalog service is healthy
• Payment gateway sandbox is available
• Email service is configured
• Inventory service is running

Blocked by: None Blocks: TC-002 (Order history verification)

---

Defects Found

---

Notes and Comments

• This is a critical path test and must pass before release
• Performance: Full checkout flow should complete in < 5 seconds
• Accessibility: All form fields must have proper ARIA labels
• Mobile: Test should also run on mobile viewport (375x667)

---

Test Execution History

---

Sign-Off

---

Template Version: 1.0 Last Updated: 2025-10-31