# E2E Non-Functional Tests Template Save as `PLANS_DIR/integration_tests/non_functional_tests.md`. --- ```markdown # E2E Non-Functional Tests ## Performance Tests ### NFT-PERF-01: [Test Name] **Summary**: [What performance characteristic this validates] **Traces to**: AC-[ID] **Metric**: [what is measured — latency, throughput, frame rate, etc.] **Preconditions**: - [System state, load profile, data volume] **Steps**: | Step | Consumer Action | Measurement | |------|----------------|-------------| | 1 | [action] | [what to measure and how] | **Pass criteria**: [specific threshold — e.g., p95 latency < 400ms] **Duration**: [how long the test runs] --- ## Resilience Tests ### NFT-RES-01: [Test Name] **Summary**: [What failure/recovery scenario this validates] **Traces to**: AC-[ID] **Preconditions**: - [System state before fault injection] **Fault injection**: - [What fault is introduced — process kill, network partition, invalid input sequence, etc.] **Steps**: | Step | Action | Expected Behavior | |------|--------|------------------| | 1 | [inject fault] | [system behavior during fault] | | 2 | [observe recovery] | [system behavior after recovery] | **Pass criteria**: [recovery time, data integrity, continued operation] --- ## Security Tests ### NFT-SEC-01: [Test Name] **Summary**: [What security property this validates] **Traces to**: AC-[ID], RESTRICT-[ID] **Steps**: | Step | Consumer Action | Expected Response | |------|----------------|------------------| | 1 | [attempt unauthorized access / injection / etc.] | [rejection / no data leak / etc.] | **Pass criteria**: [specific security outcome] --- ## Resource Limit Tests ### NFT-RES-LIM-01: [Test Name] **Summary**: [What resource constraint this validates] **Traces to**: AC-[ID], RESTRICT-[ID] **Preconditions**: - [System running under specified constraints] **Monitoring**: - [What resources to monitor — memory, CPU, GPU, disk, temperature] **Duration**: [how long to run] **Pass criteria**: [resource stays within limit — e.g., memory < 8GB throughout] ``` --- ## Guidance Notes - Performance tests should run long enough to capture steady-state behavior, not just cold-start. - Resilience tests must define both the fault and the expected recovery — not just "system should recover." - Security tests at E2E level focus on black-box attacks (unauthorized API calls, malformed input), not code-level vulnerabilities. - Resource limit tests must specify monitoring duration — short bursts don't prove sustained compliance.