# Testing

Test strategy, test plan, test cases, E2E, performance, definition of done

# Test Strategy: Drop — Fintech Payment App

# Test Strategy: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments
> **Version:** 1.0
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Approved
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | 2026-02-23 | John | Initial strategy — aligned to Drop tech stack (Vitest + Playwright) |

---

## 1. Testing Philosophy & Principles

**Core Principles:**
1. **Tests are first-class code** — reviewed, maintained, refactored like production code
2. **Test the behavior, not the implementation** — tests enable safe refactoring
3. **Fast feedback** — unit/integration tests run in seconds; blocking tests run in < 3 minutes
4. **Tests document intent** — a failing test explains what broke and why it matters
5. **Shift left** — find bugs as early as possible, before they reach users
6. **Security-by-testing** — all security invariants (no balance column, no CVV, bcrypt-only) are encoded as automated tests

**Testing philosophy:** Drop follows the test pyramid with a fintech-specific emphasis: critical financial invariants (no stored balances, PCI-DSS compliance, pass-through model) are verified in the unit/integration layer on every commit. E2E tests cover the 5 critical user journeys (registration, login, remittance, QR payment, merchant registration). We do not aim for 100% E2E coverage — instead we validate the most valuable and highest-risk paths.

---

## 2. Test Pyramid

```mermaid
graph TB
    subgraph E2E["E2E Tests — Playwright (3 projects)"]
        E2E_DESC["5 critical user journeys<br/>user-flows + full-flows + input-chaos<br/>Slow, expensive, high-confidence"]
    end
    subgraph INT["Integration Tests — Vitest (api-endpoints, db, middleware)"]
        INT_DESC["API request/response contracts<br/>DB schema integrity + FK constraints<br/>Rate limiter + auth middleware"]
    end
    subgraph UNIT["Unit Tests — Vitest (auth, validation, transactions)"]
        UNIT_DESC["bcrypt hashing, JWT verification<br/>Fee calculations, input validation<br/>Fast, cheap, developer-owned"]
    end
    subgraph PERF["Performance Tests — Vitest benchmarks"]
        PERF_DESC["api-benchmarks.test.ts<br/>bcrypt timing, query latency<br/>50 concurrent rate limit calls"]
    end
```

### 2.1 Unit Tests

| Attribute | Value |
|-----------|-------|
| **Scope** | Individual functions: auth helpers, fee calculators, input validators |
| **External dependencies** | Mocked (no real DB, no real BaaS, no real Sumsub) |
| **Framework** | Vitest (via `npm run test`) |
| **Coverage target** | ≥ 80% overall; 100% for auth + transaction paths |
| **Execution time** | Full suite < 30 seconds |
| **Runs on** | Every commit, pre-commit hook, CI |
| **Written by** | Builder agent (Claude Sonnet) + reviewed by Validator |

**What to unit test:**
- `verifyPassword` — bcrypt correctness; SHA-256 hash rejection
- `signJWT` / `verifyJWT` — JWT signing, tampered token rejection
- Fee calculation — 0.5% remittance fee, 1% QR fee
- Input validation — age ≥ 18, Norwegian phone (+47), password length, XSS/injection rejection

**What NOT to unit test:**
- Framework boilerplate (Next.js API routes scaffolding)
- Third-party library internals (jose, bcrypt)
- Simple data fetching without logic

### 2.2 Integration Tests

| Attribute | Value |
|-----------|-------|
| **Scope** | API endpoints, DB schema, middleware (rate limiter, auth middleware) |
| **External dependencies** | Real SQLite test DB; mock BaaS (NEXT_PUBLIC_SERVICE_MODE=mock) |
| **Framework** | Vitest |
| **Coverage target** | All 26 API routes tested; all DB invariants asserted |
| **Execution time** | Full suite < 2 minutes |
| **Runs on** | Every PR, blocking merge |
| **Written by** | Builder agent + Validator |

**What to integration test:**
- `api-endpoints.test.ts` — all 26 routes: status codes, response shapes, auth gating
- `db.test.ts` — schema invariants: no balance column, no card_number/cvv, FK constraints, transaction type enum
- `middleware.test.ts` — rate limiting (10 req/min auth; 429 on 11th); JWT auth; CSRF protection
- `auth.test.ts` — bcrypt rounds 12; SHA-256 rejection; JWT tampered token rejection

### 2.3 E2E Tests

| Attribute | Value |
|-----------|-------|
| **Scope** | Critical user journeys through the real staging environment |
| **External dependencies** | Real staging (https://drop-staging.fly.dev/) with mock BaaS |
| **Framework** | Playwright (3 projects: user-flows, full-flows, input-chaos) |
| **Coverage target** | 5 critical journeys; input-chaos covers 20+ validation edge cases |
| **Execution time** | Full suite < 10 minutes |
| **Runs on** | Post-staging deploy, pre-production gate |
| **Written by** | QA + Builder agent collaboration |

**Critical journeys covered by E2E:**
1. User registration (3 steps: email+DOB → OTP → PIN)
2. User login + dashboard access
3. Remittance (NOK → RSD/BAM/PKR/TRY/PLN/EUR)
4. QR payment (scan → confirm → receipt)
5. Merchant registration + QR code generation

---

## 3. Testing Tools

| Type | Tool | Version | Purpose | Config File |
|------|------|---------|---------|-------------|
| Unit + Integration | Vitest | 2.x | Unit/integration tests | `vitest.config.ts` |
| E2E testing | Playwright | 1.x | Browser E2E (3 projects) | `playwright.config.ts` |
| Coverage | Vitest (`@vitest/coverage-v8`) | Built-in | Coverage reports | `vitest.config.ts` |
| Performance | Vitest (bench) | Built-in | Benchmark tests | `api-benchmarks.test.ts` |
| Mocking | Vitest (`vi.mock`) | Built-in | Mock BaaS, Sumsub, external deps | Built-in |
| CI/CD | GitHub Actions | — | Automated CI pipeline | `.github/workflows/` |

---

## 4. Test Environments & Data Management

### Test Environments

| Test Type | Environment | Database | External Services |
|-----------|-------------|----------|------------------|
| Unit | Local (no env) | None / in-memory | Mocked via `vi.mock` |
| Integration | Local + CI | SQLite test DB (`:memory:` or temp file) | Mock BaaS (`NEXT_PUBLIC_SERVICE_MODE=mock`) |
| E2E | Staging (Fly.io, Stockholm) | Staging SQLite / PostgreSQL | Mock BaaS + Mock Sumsub |
| Performance | Local (api-benchmarks.test.ts) | SQLite | Mock |

### Test Data Management

| Approach | Used For | Tool | Notes |
|----------|----------|------|-------|
| Fixtures in test files | Unit + integration tests | Vitest `beforeEach`/`afterEach` | Reset per test |
| Database seeding | E2E tests | `npm run db:seed` | Reset per test run |
| Synthetic seed data only | All tests | Hardcoded test data | NEVER use real user data (NFR-D04) |
| Shared test accounts | E2E (consumer + merchant roles) | Vaultwarden "Drop UAT" entries | Never modified by tests |

**Data cleanup policy:** All test data cleaned up after test run via Vitest `afterEach` teardown hooks. SQLite test DB wiped between runs.

---

## 5. Test Automation Strategy

| Test Type | Automation | Trigger | Tooling |
|-----------|------------|---------|---------|
| Unit tests | 100% automated | Pre-commit + CI | Vitest |
| Integration tests | 100% automated | CI on PR | Vitest |
| E2E (critical paths) | 100% automated | Post-staging deploy | Playwright |
| E2E (input-chaos) | 100% automated | Post-staging deploy | Playwright input-chaos project |
| Performance tests | Automated baseline | Every CI run | Vitest benchmarks (api-benchmarks.test.ts) |
| Security (SAST) | 100% automated | Every PR | GitHub Actions + `npm audit` |
| DB compliance | 100% automated | Every commit | `db.test.ts` (Vitest) |
| Manual exploratory | Manual | Pre-release UAT | CEO (Alem) |

---

## 6. Manual Testing Scope

**Manual testing is required for:**
- CEO (Alem) UAT walkthrough before Phase 1 production launch
- BankID SCA flow (Phase 2 — not yet integrated)
- Real BaaS payment flow (Phase 2 — mock only in MVP)
- Mobile device testing on physical iOS/Android hardware (Playwright covers 375px viewport)
- Accessibility usability on actual assistive technology

**Manual testing is NOT required for:**
- Regression of all automated test paths
- Fee calculations (fully automated in unit tests)
- Input validation (covered by input-chaos Playwright project)
- DB compliance checks (fully automated in db.test.ts)

---

## 7. Code Coverage Requirements

| Layer | Lines | Branches | Functions | Notes |
|-------|-------|----------|-----------|-------|
| Auth module | 100% | 100% | 100% | Strictly enforced — financial security |
| Transaction processing | 100% | 100% | 100% | Strictly enforced — financial correctness |
| API handlers | ≥ 80% | ≥ 70% | ≥ 80% | |
| Input validation | ≥ 90% | ≥ 85% | 100% | Security-critical |
| DB layer | ≥ 90% | — | ≥ 90% | Compliance assertions required |
| **Overall minimum** | **≥ 80%** | — | — | CI gate — build fails below |

**Coverage enforcement:** CI pipeline fails if coverage drops below 80% overall
**Coverage report:** Published as CI artifact on every PR

---

## 8. Quality Gates

### PR Merge Gate (must pass before merge)
- [ ] All unit tests pass (`npm run test`)
- [ ] All integration tests pass
- [ ] Coverage ≥ 80% (≥ 100% for auth + transaction paths)
- [ ] No HIGH/CRITICAL security findings (`npm audit`)
- [ ] No secrets detected (pre-commit hook)
- [ ] TypeScript compiles (`npm run type-check`)
- [ ] Linting passes (`npm run lint`)

### Staging Deploy Gate
- [ ] All PR gates passed
- [ ] Build artifact created and pushed to Fly.io

### Production Deploy Gate (must pass before production deploy)
- [ ] All Playwright E2E tests pass on staging (user-flows, full-flows, input-chaos)
- [ ] Performance baseline not degraded > 10% (api-benchmarks.test.ts)
- [ ] Manual UAT sign-off from Alem Bašić (CEO)
- [ ] Security audit score ≥ 80/100

---

## 9. Responsibility Matrix

| Test Type | Writes Tests | Reviews Tests | Maintains Tests | Signs Off |
|-----------|-------------|---------------|-----------------|-----------|
| Unit tests | Builder agent | Validator agent | Builder agent | John (AI Director) |
| Integration tests | Builder agent | Validator agent | Builder agent | John (AI Director) |
| E2E tests | Builder agent | Validator agent | Builder agent | John (AI Director) |
| Performance tests | Builder agent | Validator agent | Builder agent | John (AI Director) |
| Security tests (automated) | Builder agent | Validator agent | Builder agent | John (AI Director) |
| DB compliance tests (db.test.ts) | Builder agent | Validator agent | Builder agent | John (AI Director) |
| UAT (manual) | N/A | John | N/A | Alem Bašić (CEO) |

---

## 10. Test Reporting & Metrics

| Metric | Target | Reporting |
|--------|--------|-----------|
| Test pass rate | ≥ 100% (unit/integration), ≥ 95% (E2E) | CI dashboard |
| Flaky test rate | < 2% | Per-run analysis |
| Test execution time (unit+integration) | < 3 minutes total | CI dashboard |
| Coverage trend | Stable or improving | PR comments |
| DB compliance tests | 100% pass always | CI dashboard |

---

## 11. Continuous Testing in CI/CD

| Stage | Tests Run | Blocking |
|-------|-----------|---------|
| Pre-commit (local) | Unit tests, linting, type-check | Yes |
| PR open / update | Unit + integration + SAST (`npm audit`) | Yes — blocks merge |
| Staging deploy | Playwright E2E (all 3 projects) | Yes — blocks production |
| Production deploy | Smoke tests (health + critical journeys) | Yes — auto-rollback on failure |
| Scheduled (nightly) | Full E2E suite | No — alerts only |

**Current test inventory (14 test files):**
- Unit: `auth.test.ts`, `validation.test.ts`, `transactions.test.ts`, `rates.test.ts`
- Integration: `api-endpoints.test.ts`, `db.test.ts`, `middleware.test.ts`
- Performance: `api-benchmarks.test.ts`
- Regression: `regression-suite.test.ts`, `feature-flags.test.ts`, `sumsub-integration.test.ts`, `cards-integration.test.ts`
- E2E: `user-flows.spec.ts`, `full-flows.spec.ts`, `input-chaos.spec.ts`

---

## Related Documents

- [Test Plan](./test-plan.md)
- [E2E Test Plan](./e2e-test-plan.md)
- [Performance Test Plan](./performance-test-plan.md)
- [Definition of Done](./definition-of-done.md)
- [Testing Guide](../../docs/testing/TESTING-GUIDE.md)
- [Test Inventory](../../docs/testing/TEST-INVENTORY.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-23 | Approved (AI) |
| QA Lead | Validator Agent | 2026-02-23 | Approved (AI) |
| AI Director (John) | John | 2026-02-23 | Approved |
| CEO (Alem) | Alem Bašić | TBD | |

# Test Plan: Drop — Fintech Payment App

# Test Plan: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments
> **Version:** 1.0
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Approved
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | 2026-02-23 | John | Initial test plan — all MVP modules |

---

## 1. Test Objectives

This test plan covers testing for **Drop MVP + Phase 0.5 Security Hardening** (v0.5.0).

**Primary objectives:**
1. Verify that all authentication and onboarding flows (registration, OTP, PIN, login) work correctly for Norwegian residents (age ≥ 18, phone +47)
2. Verify that remittance transactions apply correct 0.5% fee across all 6 NOK corridors with mock BaaS
3. Verify that QR payments apply correct 1% merchant fee with mock BaaS
4. Confirm the pass-through model invariant: Drop NEVER stores user balances or full card data
5. Confirm Phase 0.5 security hardening: bcrypt 12 rounds, persistent rate limiting, CSRF, security headers, audit logging
6. Validate performance under expected load (40+ concurrent users; target 200 for Phase 1)

**Out of scope for this plan:** BankID SCA (Phase 2), real BaaS payments (Phase 2), real Sumsub KYC (Phase 2), Cards feature (Phase 3), mobile native app (Phase 2).

---

## 2. Features Under Test

| Feature / Story | Priority | Test Types | Owner |
|-----------------|----------|------------|-------|
| User Registration — 3-step (FR-001) | Critical | Unit, Integration, E2E | Builder + Validator |
| User Login (FR-002) | Critical | Unit, Integration, E2E | Builder + Validator |
| Remittance Transaction (FR-020) | Critical | Unit, Integration, E2E | Builder + Validator |
| Exchange Rates API (FR-021) | High | Integration | Builder + Validator |
| QR Payment — Consumer (FR-030) | Critical | Unit, Integration, E2E | Builder + Validator |
| Merchant Registration + QR (FR-031) | High | Unit, Integration | Builder + Validator |
| Rate Limiting (NFR-SEC05) | Critical | Integration | Builder + Validator |
| Input Validation / Security (NFR-SEC06) | Critical | Unit, E2E (input-chaos) | Builder + Validator |
| DB Compliance — No Balance/CVV (NF-AC-020/021) | Critical | Integration (db.test.ts) | Builder + Validator |
| bcrypt Hashing (NFR-SEC02) | Critical | Unit (auth.test.ts) | Builder + Validator |
| Performance Benchmarks (NFR-P01..P06) | High | Performance (api-benchmarks) | Builder + Validator |
| Feature Flags (FR-090) | Medium | Unit (feature-flags.test.ts) | Builder + Validator |

---

## 3. Scope

### In Scope

- Authentication module: registration, OTP verification, PIN setup, login, logout, `/api/auth/me`
- Remittance module: `POST /api/transactions/remittance`, `GET /api/transactions`, exchange rates
- QR payments module: `POST /api/transactions/qr-payment`, `POST /api/merchants`, `GET /api/merchants/me`
- Security middleware: rate limiting, CSRF, JWT validation, security headers
- Database compliance: schema assertions (no balance, no card_number, no cvv), FK constraints, transaction type enum
- Performance benchmarks: bcrypt timing, DB query latency, concurrent rate limit check throughput
- Regression testing of all 26 API routes
- Input validation: XSS, SQL injection, boundary ages, Unicode names, long passwords

### Out of Scope

| Item | Justification |
|------|---------------|
| BankID SCA integration | Phase 2 — not yet implemented |
| Real BaaS PISP/AISP payments | Phase 2 — mock mode only in MVP |
| Real Sumsub KYC webhooks | Phase 2 — auto-approved in MVP |
| Cards feature | Phase 3 — feature-flagged OFF |
| Mobile native app | Phase 2 — web only in MVP |
| Load testing > 200 concurrent users | Phase 1 migration to PostgreSQL required first |

---

## 4. Test Schedule & Milestones

| Milestone | Date | Responsible |
|-----------|------|-------------|
| Test plan approved | 2026-02-23 | John (AI Director) |
| Test environment ready (staging) | Before Phase 0.5 release | John (DevOps) |
| Test data seeded | Before E2E run | Builder agent |
| Unit + integration tests complete | Per PR (CI automated) | Builder agent |
| Playwright E2E authoring complete | Before Phase 0.5 release | Builder agent |
| Regression testing complete (all 26 routes) | Before Phase 0.5 release | Validator agent |
| Performance benchmarks run | Before Phase 0.5 release | Builder agent |
| UAT start (CEO walkthrough) | TBD — before Phase 1 launch | John |
| UAT sign-off | TBD | Alem Bašić (CEO) |
| Go/no-go decision | Before Phase 1 launch | Alem Bašić (CEO) |
| Production release | Phase 1 (BaaS partner confirmed) | John (AI Director) |

---

## 5. Resource Allocation

| Resource | Role | Testing Activities | Availability |
|----------|------|-------------------|-------------|
| Builder Agent (Claude Sonnet) | Developer / QA | Unit + integration + E2E authoring | Per task |
| Validator Agent (Claude Sonnet, read-only) | QA Lead | Code review + test verification | Per task |
| John (AI Director) | Tech Lead | Test strategy, UAT coordination | Continuous |
| Alem Bašić (CEO) | Product Owner / UAT | CEO UAT walkthrough | TBD |

---

## 6. Entry Criteria

Testing may begin when:
- [ ] Feature development is code-complete (all tickets in "Ready for QA")
- [ ] Unit tests passing (≥ 100% pass rate on unit + integration suite)
- [ ] Build artifact deployed to staging (https://drop-staging.fly.dev/)
- [ ] Staging environment is stable (health checks passing)
- [ ] Test data is seeded (`npm run db:seed`)
- [ ] Previous known blocking bugs resolved (Mission Control backlog reviewed)

---

## 7. Exit Criteria

Testing is complete when:
- [ ] All 14 test files execute cleanly
- [ ] ≥ 100% of unit + integration tests pass
- [ ] All Critical and High test cases in AC-001–AC-092 pass
- [ ] Code coverage ≥ 80% overall; 100% for auth + transaction paths
- [ ] All Playwright E2E tests passing on staging (user-flows, full-flows, input-chaos)
- [ ] Performance benchmarks meeting NFR-P01..P06 targets (api-benchmarks.test.ts green)
- [ ] DB compliance tests passing (db.test.ts: no balance, no card_number/cvv columns)
- [ ] UAT sign-off obtained from Alem Bašić (CEO) — or conditional approval documented
- [ ] Security audit score ≥ 80/100 (post Phase 0.5 hardening)

**Exceptional circumstances:** If exit criteria cannot be met, a documented risk acceptance from Alem Bašić (CEO) is required.

---

## 8. Test Strategy Summary Per Type

| Type | Approach | Tool | Owner | Gate |
|------|----------|------|-------|------|
| Unit | White-box — bcrypt, JWT, fee calc, validators | Vitest | Builder | Blocks merge |
| Integration | Real SQLite test DB — 26 API routes, DB schema | Vitest | Builder | Blocks merge |
| E2E | Critical journeys on staging — 3 Playwright projects | Playwright | Builder | Blocks release |
| Regression | All 26 routes via api-endpoints.test.ts | Vitest | Builder | Blocks merge |
| Performance | api-benchmarks.test.ts — bcrypt timing, query latency | Vitest bench | Builder | Warning → release |
| Security | `npm audit` + validation.test.ts + middleware.test.ts | Vitest + GitHub Actions | Builder | Blocks merge |
| DB compliance | db.test.ts — schema assertions | Vitest | Builder | Blocks merge |
| UAT | CEO business scenario walkthrough | Manual | Alem Bašić | Blocks Phase 1 launch |

---

## 9. Test Environment Requirements

| Environment | Purpose | URL | Access Needed |
|-------------|---------|-----|---------------|
| Local dev | Unit/integration | `http://localhost:3000` | Builder agent |
| Staging (Fly.io, Stockholm) | E2E, regression, UAT | `https://drop-staging.fly.dev/` | Team + Alem |
| Performance | Benchmarks | Local (api-benchmarks.test.ts) | Builder agent |

**Environment requirements:**
- Staging must have `NEXT_PUBLIC_SERVICE_MODE=mock` (no real BaaS)
- Staging SQLite DB seeded with synthetic test data (no real PII)
- Monitoring enabled (Fly.io metrics)

---

## 10. Test Data Requirements

| Data Category | Volume | Creation Method | Responsible |
|---------------|--------|----------------|-------------|
| Test consumer accounts | 3 (fresh, KYC-approved, KYC-pending) | `npm run db:seed` | Builder agent |
| Test merchant accounts | 2 (registered, unregistered) | `npm run db:seed` | Builder agent |
| Test recipients (for remittance) | 3 | `npm run db:seed` | Builder agent |
| Edge case data (under-18, duplicate email, max amounts) | Defined per test | Vitest fixtures | Builder agent |

**Data cleanup:** All test data removed after test run via Vitest `afterEach` teardown. Staging DB reset between major test runs.

---

## 11. Risk-Based Test Prioritization

| Risk Area | Likelihood | Impact | Priority | Mitigation |
|-----------|------------|--------|----------|------------|
| Pass-through model violation (Drop stores balance) | Low | Critical | P1 | db.test.ts always asserts no balance column |
| Authentication bypass | Low | Critical | P1 | Full auth.test.ts suite + middleware.test.ts |
| Fee calculation error (wrong percentage) | Medium | Critical | P1 | Unit tests for 0.5% and 1% fee calculations |
| Double-spend race condition | Low | Critical | P1 | Transaction lock integration test |
| Rate limiter reset on server restart | Medium (was a bug) | High | P2 | middleware.test.ts with persistent limiter |
| BaaS mock mode leaking to production config | Low | High | P2 | CI check for `NEXT_PUBLIC_SERVICE_MODE` env var |
| SQLite concurrent write limit reached | High (at ~200 users) | Medium | P3 | Phase 1: PostgreSQL migration |

---

## 12. Dependencies & Assumptions

**Dependencies:**
- Staging environment provisioned and accessible at https://drop-staging.fly.dev/
- Mock BaaS and Mock Sumsub configured in staging environment variables
- Playwright installed in CI (`npx playwright install`)

**Assumptions:**
- Feature requirements will not change during the testing phase without John (AI Director) review
- All Builder agent PRs include tests alongside code
- Validator agent reviews test files before merge
- BaaS partnership not confirmed — mock mode accepted for MVP/staging

---

## 13. Defect Management Process

**Bug tracker:** Mission Control tasks + Slack #drop-bugs on alai-talk.slack.com
**Severity levels:**

| Severity | Definition | Resolution SLA |
|----------|------------|----------------|
| Critical | Financial invariant broken; auth bypass; data loss | Fix before release — no exceptions |
| High | Major feature broken; security finding; no workaround | Fix before release |
| Medium | Feature degraded; mock/workaround exists | Fix in next sprint |
| Low | Minor issue, cosmetic | Backlog |

**Bug lifecycle:** Open → Assigned (Mission Control) → In Progress → Fixed → Verified by Validator → Closed
**Triage cadence:** On each PR/commit (CI-driven); daily for active test phase

---

## 14. Test Deliverables

| Deliverable | Format | Due Date | Owner |
|-------------|--------|----------|-------|
| Test plan (this document) | Markdown | 2026-02-23 | John (AI Director) |
| Test strategy | [test-strategy.md](./test-strategy.md) | 2026-02-23 | John |
| Test cases (automated) | Vitest + Playwright test files | Per sprint | Builder agent |
| Test execution results | Vitest + Playwright CI reports | Per PR | CI |
| Performance test report | api-benchmarks.test.ts output | Per release | Builder agent |
| UAT sign-off | [uat-signoff.md](../RELEASE/uat-signoff.md) | Before Phase 1 | Alem Bašić |
| Test summary report | Markdown (per release) | Per release | Validator agent |

---

## Related Documents

- [Test Strategy](./test-strategy.md)
- [Test Case Template](./test-case-template.md)
- [E2E Test Plan](./e2e-test-plan.md)
- [Performance Test Plan](./performance-test-plan.md)
- [Definition of Done](./definition-of-done.md)
- [UAT Sign-off](../RELEASE/uat-signoff.md)
- [Testing Guide](../../docs/testing/TESTING-GUIDE.md)
- [Test Inventory](../../docs/testing/TEST-INVENTORY.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-23 | Approved (AI) |
| QA Lead | Validator Agent | 2026-02-23 | Approved (AI) |
| AI Director (John) | John | 2026-02-23 | Approved |
| CEO (Alem) | Alem Bašić | TBD | |

# Test Case Template: Drop — Fintech Payment App

# Test Case Template: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments
> **Version:** 1.0
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Approved
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | 2026-02-23 | John | Initial test case template with Drop-specific examples |

---

## 1. Test Case ID Format & Naming Convention

**Format:** `TC-{MODULE_CODE}-{SEQUENCE}`

| Part | Description | Example |
|------|-------------|---------|
| `TC` | Test Case prefix (always TC) | `TC` |
| `MODULE_CODE` | 2-4 letter module abbreviation | `AUTH`, `REM`, `QR`, `SEC`, `DB`, `PERF` |
| `SEQUENCE` | 3-digit zero-padded number | `001`, `042`, `100` |

**Drop Module Codes:**
- `AUTH` — Authentication & Onboarding
- `REM` — Remittance (Send Money)
- `QR` — QR Payments (Consumer + Merchant)
- `SEC` — Security & Input Validation
- `DB` — Database Compliance (no balance, no CVV)
- `PERF` — Performance Benchmarks
- `RATE` — Exchange Rates API
- `SMK` — Smoke Tests (critical path subset)

**Examples:**
- `TC-AUTH-001` — Authentication module, registration test
- `TC-REM-015` — Remittance module, fee calculation test
- `TC-DB-001` — DB compliance, no balance column test

**Related requirement ID:** Link to `AC-{ID}` (acceptance criteria) or `FR-{ID}` (functional requirement)

---

## 2. Test Suite Organization

| Suite ID | Suite Name | Module | Test Cases | Owner |
|----------|------------|--------|------------|-------|
| TS-AUTH | Authentication | auth.test.ts | TC-AUTH-001 to TC-AUTH-020 | Builder + Validator |
| TS-REM | Remittance | transactions.test.ts | TC-REM-001 to TC-REM-020 | Builder + Validator |
| TS-QR | QR Payments | transactions.test.ts | TC-QR-001 to TC-QR-010 | Builder + Validator |
| TS-SEC | Security / Validation | validation.test.ts, middleware.test.ts | TC-SEC-001 to TC-SEC-030 | Builder + Validator |
| TS-DB | DB Compliance | db.test.ts | TC-DB-001 to TC-DB-010 | Builder + Validator |
| TS-RATE | Exchange Rates | rates.test.ts | TC-RATE-001 to TC-RATE-005 | Builder + Validator |
| TS-PERF | Performance | api-benchmarks.test.ts | TC-PERF-001 to TC-PERF-010 | Builder + Validator |
| TS-E2E | E2E User Journeys | user-flows.spec.ts, full-flows.spec.ts | TC-E2E-001 to TC-E2E-020 | Builder + Validator |
| TS-CHAOS | Input Chaos | input-chaos.spec.ts | TC-CHAOS-001 to TC-CHAOS-030 | Builder + Validator |
| TS-SMK | Smoke Tests | user-flows.spec.ts (subset) | TC-SMK-001 to TC-SMK-005 | Builder + Validator |
| TS-REG | Regression Suite | api-endpoints.test.ts | All high-priority TCs | Builder + Validator |

---

## 3. Individual Test Case Format

---

### Test Case: TC-{MODULE}-{SEQ}

| Field | Value |
|-------|-------|
| **ID** | TC-{MODULE}-{SEQ} |
| **Title** | {CONCISE_DESCRIPTION} |
| **Description** | {FULL_DESCRIPTION} — 1-3 sentences explaining what is being verified and why |
| **Module / Feature** | {MODULE_NAME} |
| **Priority** | {PRIORITY} — Critical / High / Medium / Low |
| **Type** | {TYPE} — Functional / Regression / Smoke / Boundary / Negative / Performance / Security / Compliance |
| **Requirement** | {AC_ID} / {FR_ID} |
| **Automation Status** | Automated / Manual / Planned |
| **Automation ID** | {test_file_path}:{test_name} |

#### Preconditions

1. {PRECONDITION_1}
2. {PRECONDITION_2}
3. {PRECONDITION_3}

#### Test Data

| Field | Value | Notes |
|-------|-------|-------|
| {Field} | `{value}` | Stored in Vaultwarden "Drop UAT" |

#### Test Steps

| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | {ACTION_1} | {EXPECTED_1} |
| 2 | {ACTION_2} | {EXPECTED_2} |
| 3 | {ACTION_3} | {EXPECTED_3} |

#### Expected Final Result

{OVERALL_EXPECTED_RESULT}

#### Post-conditions

- {POSTCONDITION_1}
- {POSTCONDITION_2}

---

## 4. Priority Definitions

| Priority | Definition | Drop Examples |
|----------|------------|----------|
| **Critical** | Core functionality; financial invariant; auth; Pass-through model | Login, remittance, db.test.ts no-balance assertion |
| **High** | Important feature; significant user impact if broken | Exchange rates, merchant registration, KYC gate |
| **Medium** | Standard feature; workaround exists | Feature flags, notification preferences |
| **Low** | Minor feature, cosmetic, or edge case | Error message wording, UI sorting |

---

## 5. Test Case Type Definitions

| Type | Description |
|------|-------------|
| **Functional** | Verifies a Drop feature works as specified |
| **Regression** | Verifies previously working functionality still works after code change |
| **Smoke** | Fast check of most critical paths (subset for quick confidence — 5 tests) |
| **Boundary** | Tests at the edges of valid input (e.g., exactly 18 years old; amount = 100 NOK min) |
| **Negative** | Tests invalid input, error conditions, unauthorized access |
| **Performance** | Verifies response time, throughput under defined load (api-benchmarks.test.ts) |
| **Security** | Verifies access controls, injection resistance, bcrypt, JWT |
| **Compliance** | Verifies regulatory requirements (PCI-DSS no CVV; GDPR no excess data; AML transaction limits) |

---

## 6. Batch Test Execution Template

**Test Run:** {RUN_ID}
**Environment:** Staging (https://drop-staging.fly.dev/)
**Build / Version:** v{VERSION}
**Tester:** Validator Agent + Builder Agent
**Date:** {DATE}

| Test Case ID | Title | Priority | Result | Actual Result / Notes | Defect ID |
|-------------|-------|----------|--------|-----------------------|-----------|
| TC-AUTH-001 | User registers successfully | Critical | | | |
| TC-AUTH-002 | Under-18 rejected | Critical | | | |
| TC-AUTH-003 | Login with valid credentials | Critical | | | |
| TC-REM-001 | Remittance fee = 0.5% | Critical | | | |
| TC-QR-001 | QR payment fee = 1% | Critical | | | |
| TC-DB-001 | No balance column in users table | Critical | | | |
| TC-DB-002 | No card_number/cvv in cards table | Critical | | | |

**Summary:**
- Total: {TOTAL}
- Passed: {PASSED}
- Failed: {FAILED}
- Blocked: {BLOCKED}
- Pass rate: {PASS_RATE}%

---

## 7. Test Execution Log Format

| Timestamp | Test Case ID | Tester | Environment | Build | Result | Duration | Notes |
|-----------|-------------|--------|-------------|-------|--------|----------|-------|
| {TIMESTAMP} | TC-AUTH-001 | Validator | staging | v0.5.0 | Pass | 1.2s | |

---

## 8. Defect Linking

**Defect format:** `BUG-{ID}` (in Mission Control)

| Test Case | Defect ID | Severity | Status | Fixed In |
|-----------|-----------|----------|--------|----------|
| TC-{MODULE}-{SEQ} | BUG-{ID} | {SEVERITY} | Open / Fixed / Verified | v{VERSION} |

**Defect fields required:**
- Steps to reproduce (reference test case ID)
- Expected vs actual behavior
- Environment + build version
- Screenshot / screen recording (for E2E failures)
- Severity and priority
- Vitest / Playwright error output

---

## Example Test Cases — Drop Specific

---

### Test Case: TC-AUTH-001

| Field | Value |
|-------|-------|
| **ID** | TC-AUTH-001 |
| **Title** | User registers successfully with valid Norwegian phone and age ≥ 18 |
| **Description** | Verifies that a new user can complete 3-step registration: email+DOB → OTP → PIN. Tests the core Drop onboarding business process. |
| **Module / Feature** | Authentication — User Registration |
| **Priority** | Critical |
| **Type** | Functional |
| **Requirement** | AC-001, FR-001, BR-001 |
| **Automation Status** | Automated |
| **Automation ID** | `src/drop-app/__tests__/auth.test.ts:successful registration` |

#### Preconditions
1. Fresh email address not previously registered in Drop
2. Norwegian phone number (+47)
3. DOB indicating age ≥ 18 (e.g., born 20 years ago)

#### Test Data
| Field | Value | Notes |
|-------|-------|-------|
| Email | `e2e-fresh-{timestamp}@test.alai.no` | Unique per test run |
| Password | `TestDrop123!` | ≥ 8 chars |
| Phone | `+4712345678` | Norwegian format |
| DOB | 20 years ago from test date | Age = 20 years |
| First Name | `Amir` | Unicode safe |
| Last Name | `Hasić` | With diacritics |

#### Test Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | POST `/api/auth/register` with valid payload | 201 Created; user in DB; no password hash in response |
| 2 | POST `/api/auth/verify-otp` with correct 6-digit OTP | 200; user proceeds to PIN step |
| 3 | POST `/api/auth/setup-pin` with valid 4-digit PIN | 200; account activated; JWT httpOnly cookie set |
| 4 | GET `/api/auth/me` with JWT cookie | 200; user object returned; no password hash |

#### Expected Final Result
Account created and activated. JWT httpOnly cookie set. User redirected to dashboard. Password hash NEVER appears in any API response. No balance column in user record.

#### Post-conditions
- User exists in DB with kyc_status = 'pending' (mock) or 'approved' (auto in dev mode)
- Audit log entry created for registration event
- Test cleanup: delete user in `afterEach`

#### Notes / Edge Cases
- Related: TC-AUTH-002 (under-18 rejection)
- Unicode test: Bosnian diacritics in name must be stored correctly (AC-083)

---

### Test Case: TC-AUTH-002

| Field | Value |
|-------|-------|
| **ID** | TC-AUTH-002 |
| **Title** | Under-18 registration rejected with Norwegian error message |
| **Description** | Verifies that a user born less than 18 years ago receives a 422 error in Norwegian: "Du må være minst 18 år". |
| **Module / Feature** | Authentication — Age Validation |
| **Priority** | Critical |
| **Type** | Negative / Compliance |
| **Requirement** | AC-004, FR-001, BR-002 |
| **Automation Status** | Automated |
| **Automation ID** | `src/drop-app/__tests__/auth.test.ts:under-18 rejected` |

#### Preconditions
1. Registration form accessible

#### Test Data
| Field | Value | Notes |
|-------|-------|-------|
| DOB | Today minus 17 years | Age = 17 years old |
| Email | `underaged@test.alai.no` | |

#### Test Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | POST `/api/auth/register` with DOB indicating age < 18 | 422 Unprocessable Entity |
| 2 | Check response body | Error message contains "Du må være minst 18 år" |
| 3 | Check DB | No user record created |

#### Expected Final Result
422 response with Norwegian age validation error. No account created.

---

### Test Case: TC-DB-001

| Field | Value |
|-------|-------|
| **ID** | TC-DB-001 |
| **Title** | Users table has NO balance column — pass-through model invariant |
| **Description** | Verifies that the pass-through model architectural invariant is enforced: Drop NEVER stores user balances. Balance is always read from the bank via AISP. |
| **Module / Feature** | Database Compliance |
| **Priority** | Critical |
| **Type** | Compliance |
| **Requirement** | NF-AC-020, NFR-COMP05, ADR-003 (pass-through model) |
| **Automation Status** | Automated |
| **Automation ID** | `src/drop-app/__tests__/db.test.ts:users table has no balance column` |

#### Preconditions
1. Database initialized with current schema

#### Test Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | Query SQLite schema: `PRAGMA table_info(users)` | Column list returned |
| 2 | Assert `balance` not in column list | Test passes — no balance column exists |

#### Expected Final Result
Test passes. DB schema has no `balance` column in `users` table.

#### Notes / Edge Cases
- This test must NEVER be skipped or disabled
- Any migration adding a balance column must be immediately reverted as it violates ADR-003
- Related: TC-DB-002 (no card_number/cvv), TC-DB-003 (FK constraints enabled)

---

### Test Case: TC-REM-001

| Field | Value |
|-------|-------|
| **ID** | TC-REM-001 |
| **Title** | Remittance fee calculated correctly at 0.5% |
| **Description** | Verifies that the remittance fee is exactly 0.5% of the transaction amount (not 0.5% of total debit). |
| **Module / Feature** | Remittance — Fee Calculation |
| **Priority** | Critical |
| **Type** | Functional / Boundary |
| **Requirement** | AC-030, AC-031, FR-020 |
| **Automation Status** | Automated |
| **Automation ID** | `src/drop-app/__tests__/transactions.test.ts:fee calculation` |

#### Test Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | POST `/api/transactions/remittance` with amount=1000, currency=RSD | 201 Created |
| 2 | Check response: fee field | fee = 5 NOK (exactly 0.5% of 1000) |
| 3 | POST with amount=2000 | 201; fee = 10 NOK |
| 4 | POST with amount=99 (below minimum) | 400 "Amount must be between 100 and 50000 NOK" |
| 5 | POST with amount=50001 (above maximum) | 400 validation error |

#### Expected Final Result
Fee = amount × 0.005. Minimum 100 NOK; maximum 50,000 NOK per transaction.

---

## Related Documents

- [Test Strategy](./test-strategy.md)
- [Test Plan](./test-plan.md)
- [E2E Test Plan](./e2e-test-plan.md)
- [Acceptance Criteria](../BUSINESS-REQUIREMENTS/acceptance-criteria.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-23 | Approved (AI) |
| QA Lead | Validator Agent | 2026-02-23 | Approved (AI) |
| AI Director (John) | John | 2026-02-23 | Approved |
| CEO (Alem) | Alem Bašić | TBD | |

# E2E Test Plan

# E2E Test Plan

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. E2E Testing Objectives

<!-- GUIDANCE: E2E tests are expensive to write and maintain. Be clear about what value they provide and limit scope to what matters most. -->

**Objectives:**
1. Validate that the {{COUNT}} most critical user journeys work end-to-end in a production-like environment
2. Catch integration failures between frontend, backend, and third-party services that unit/integration tests cannot detect
3. Provide confidence before every production deployment
4. Serve as living documentation of critical user flows

**What E2E tests are NOT for:**
- Complete feature coverage (that's for unit/integration tests)
- Testing every error state (too expensive to maintain)
- Performance benchmarking (use performance tests)
- Visual pixel-perfection (use visual regression tests separately)

---

## 2. Critical User Journeys

<!-- GUIDANCE: Define each journey as the user sees it, not the technical steps. Prioritize by business impact. -->

### Journey 1: {{JOURNEY_1_NAME}}

| Field | Value |
|-------|-------|
| **Priority** | Critical |
| **Business Impact** | {{IMPACT}} <!-- e.g., "Core revenue path" --> |
| **Frequency** | {{FREQUENCY}} <!-- How often real users do this --> |
| **Test File** | `{{TEST_PATH}}` |

**Steps:**
1. {{STEP_1}} <!-- e.g., "User lands on homepage" -->
2. {{STEP_2}} <!-- e.g., "Searches for a product" -->
3. {{STEP_3}} <!-- e.g., "Selects and adds to cart" -->
4. {{STEP_4}} <!-- e.g., "Proceeds to checkout" -->
5. {{STEP_5}} <!-- e.g., "Completes payment with test card" -->
6. {{STEP_6}} <!-- e.g., "Sees order confirmation" -->

**Assertions:**
- {{ASSERTION_1}} <!-- e.g., "Confirmation email trigger verified" -->
- {{ASSERTION_2}} <!-- e.g., "Order appears in user account" -->
- {{ASSERTION_3}} <!-- e.g., "Inventory decremented correctly" -->

---

### Journey 2: {{JOURNEY_2_NAME}}

| Field | Value |
|-------|-------|
| **Priority** | Critical |
| **Business Impact** | {{IMPACT}} |
| **Frequency** | {{FREQUENCY}} |
| **Test File** | `{{TEST_PATH}}` |

**Steps:**
1. {{STEP_1}}
2. {{STEP_2}}
3. {{STEP_3}}

<!-- TODO: Add all critical user journeys. Typical minimum: registration, login, core workflow, payment/conversion, logout -->

---

### All Journeys Summary

<!-- GUIDANCE: Once all journeys are defined above, populate this summary table. -->

| Journey | Priority | Est. Duration | Automated | Last Pass |
|---------|----------|--------------|-----------|-----------|
| {{JOURNEY_1_NAME}} | Critical | {{DURATION}}s | Yes | {{DATE}} |
| {{JOURNEY_2_NAME}} | Critical | {{DURATION}}s | Yes | {{DATE}} |
| User registration + email verification | Critical | 60s | Yes | — |
| Password reset flow | High | 45s | Yes | — |
| Account settings update | Medium | 30s | Yes | — |

---

## 3. Browser & Device Matrix

<!-- GUIDANCE: Define the minimum browser/device coverage required. Balance coverage vs maintenance cost. -->

### Desktop Browsers

| Browser | Version | OS | Priority | Notes |
|---------|---------|-----|----------|-------|
| Chrome | Latest stable | Windows, macOS | Critical | Highest market share |
| Firefox | Latest stable | Windows, macOS | High | |
| Safari | Latest stable | macOS | High | WebKit engine |
| Edge | Latest stable | Windows | Medium | Chromium-based |

### Mobile Browsers

| Browser | Platform | Version | Priority | Notes |
|---------|----------|---------|----------|-------|
| Safari | iOS | Latest | Critical | Highest mobile share |
| Chrome | Android | Latest | Critical | |

### Screen Resolutions

| Category | Resolution | Test Priority |
|----------|------------|--------------|
| Desktop HD | 1920×1080 | Critical |
| Desktop | 1366×768 | High |
| Laptop | 1280×800 | Medium |
| Tablet (landscape) | 1024×768 | High |
| Mobile L | 428×926 | Critical |
| Mobile M | 375×667 | Critical |

**Matrix in CI:** Run Critical priority browser/resolution combinations on every deployment. Full matrix on nightly schedule.

---

## 4. Test Data Setup & Teardown

<!-- GUIDANCE: E2E tests must be idempotent — they should work the same way every time, regardless of order. -->

### Setup Strategy

| Data Type | Method | Scope |
|-----------|--------|-------|
| Test user accounts | Pre-seeded before test run | Test suite |
| {{DATA_TYPE}} | Created via API in `beforeAll` | Test suite |
| Isolated test data | Created via API in `beforeEach` | Individual test |

**Seed command:** `bash scripts/e2e-seed.sh {{ENVIRONMENT}}`
**Seed verification:** `bash scripts/verify-seed.sh {{ENVIRONMENT}}`

### Teardown Strategy

| Cleanup Item | Method | Trigger |
|-------------|--------|---------|
| Test-specific records | DELETE via API | `afterEach` |
| Test session data | Clear browser storage | `afterEach` |
| Emails in test inbox | API clear | `afterAll` |
| Payment test data | Stripe test mode auto-cleanup | Daily job |

**Rule:** Tests must not leave state that affects other tests. Tests must be executable in any order.

### Test Accounts

<!-- GUIDANCE: Maintain dedicated test accounts. Never use accounts that could be mistaken for real users. -->

| Account | Email | Role | Purpose |
|---------|-------|------|---------|
| Standard user | `e2e-user@test.{{DOMAIN}}` | User | Standard journeys |
| Admin user | `e2e-admin@test.{{DOMAIN}}` | Admin | Admin panel journeys |
| {{ROLE}} user | `e2e-{{ROLE}}@test.{{DOMAIN}}` | {{ROLE}} | {{PURPOSE}} |

Credentials stored in: {{CREDENTIAL_STORE}} (never hardcoded in tests)

---

## 5. Authentication Handling in Tests

<!-- GUIDANCE: Repeated login UI flows waste test time. Use API-based auth where possible. -->

**Strategy:** {{AUTH_STRATEGY}} <!-- API-based auth / UI login once + save state / Cookie injection -->

**Recommended approach (Playwright):**
```typescript
// tests/fixtures/auth.ts
// Authenticate via API, save storage state
// Reuse state across tests in the same suite
// Only use UI login when testing the login flow itself
```

**Session reuse:**
- Session state saved per role after first auth
- Reused for all tests requiring that role
- Invalidated and refreshed if expired

---

## 6. Test Environment Requirements

<!-- GUIDANCE: E2E tests need a stable, production-like environment. Document exact requirements. -->

| Requirement | Specification |
|-------------|--------------|
| Environment | Staging (`staging.{{DOMAIN}}`) |
| Database | Dedicated E2E database, seeded before run |
| External services | Sandbox / test mode (Stripe test, email sandbox) |
| Stability | No active deployments during E2E run |
| Data persistence | Isolated — not shared with manual testing |
| Response times | < {{TIMEOUT}}s for all endpoints (E2E assertions time out at 2× this) |

**Environment locking:** CI acquires a lock before E2E run to prevent concurrent deployments
**Lock mechanism:** {{LOCK_MECHANISM}}

---

## 7. Flaky Test Management Strategy

<!-- GUIDANCE: Flaky tests destroy trust in the test suite. They must be managed systematically. -->

**Definition:** A test that fails inconsistently for the same code

**Prevention:**
- Use explicit waits (not `sleep`) — wait for elements/network, not time
- Isolate test data (no shared state between tests)
- Use retry-on-assertion, not retry-on-run
- Avoid animation timing issues with `prefers-reduced-motion` in test env

**Detection:**
- Track flakiness rate per test in CI
- Any test failing > {{FLAKY_THRESHOLD}}% of runs without code changes = flaky

**Response:**
- Immediately tag flaky test with `@flaky` annotation
- Create bug ticket with priority based on journey criticality
- Quarantine (run separately, don't block CI) while fixing
- Fix within {{FLAKY_FIX_SLA}} days or remove the test
- Monthly flaky test review

---

## 8. Visual Regression Testing

<!-- GUIDANCE: Visual regression catches unintended UI changes. Run on UI-touching PRs. -->

**Tool:** {{VIS_TOOL}} <!-- Playwright screenshots / Percy / Chromatic / Storybook visual tests -->
**Baseline:** Stored in {{BASELINE_STORAGE}}
**Threshold:** Allow up to {{VIS_THRESHOLD}}% pixel difference for font rendering

| Check | Scope | Trigger |
|-------|-------|---------|
| Full page screenshots | Critical pages | UI-touching PRs |
| Component snapshots | UI components | Component changes |
| Responsive layout | Mobile + desktop | Layout changes |

**Review process:** Visual diffs in PR requiring explicit approval before merge

---

## 9. Performance Assertions Within E2E

<!-- GUIDANCE: Basic performance checks within E2E catch obvious regressions without full load testing. -->

| Assertion | Metric | Threshold | Journey |
|-----------|--------|-----------|---------|
| Page load | Time to Interactive | < {{TTI}}ms | All critical pages |
| Core Web Vitals — LCP | Largest Contentful Paint | < {{LCP}}ms | Homepage, landing pages |
| Core Web Vitals — CLS | Cumulative Layout Shift | < {{CLS}} | All pages |
| API response | Time in test assertions | < {{API_TIMEOUT}}ms | All API calls |

---

## 10. CI Integration

<!-- GUIDANCE: E2E tests in CI must be fast enough to provide timely feedback while being thorough. -->

**Trigger:** Post-staging deployment

**Parallelization:**
- Test sharding: {{SHARD_COUNT}} shards
- Browser parallelism: {{BROWSER_WORKERS}} workers per shard
- Estimated total time: {{E2E_TOTAL_TIME}} minutes

**CI configuration:**
```yaml
# Reference: {{CI_CONFIG_PATH}}
# Key settings:
# - Shards: {{SHARD_COUNT}}
# - Retries: {{RETRY_COUNT}} (for non-flaky tests only)
# - Timeout per test: {{TEST_TIMEOUT}}ms
# - Timeout total: {{SUITE_TIMEOUT}}min
```

**On failure:**
- Collect screenshots, videos, traces as artifacts
- Retain artifacts for {{ARTIFACT_RETENTION}} days
- Alert Slack channel `#e2e-failures`

---

## 11. Test Report Format & Artifacts

<!-- GUIDANCE: Good test reports help debug failures quickly without having to re-run locally. -->

**Report format:** {{REPORT_FORMAT}} <!-- HTML / JUnit XML / Allure -->
**Report location:** {{REPORT_URL}} or CI artifacts

**Artifacts collected on failure:**

| Artifact | Format | When Collected |
|----------|--------|----------------|
| Screenshot | PNG | On step failure |
| Screen recording | WebM video | On test failure |
| Network trace | HAR file | On test failure |
| Browser console log | JSON | On test failure |
| Playwright trace | `.zip` (trace viewer) | On test failure |

---

## 12. Maintenance Strategy

<!-- GUIDANCE: E2E tests rot quickly. Define how you keep them maintained. -->

**Page Object Pattern:**
- All page interactions wrapped in Page Object classes
- Selectors centralized — change in one place
- Location: `tests/e2e/pages/`

**Selector strategy:**
1. `data-testid` attributes (preferred — stable, intent-clear)
2. ARIA roles + accessible name (good for accessibility alignment)
3. Text content (acceptable for static text)
4. CSS class names (avoid — coupled to styling)
5. XPath (never — fragile)

**Review cadence:**
- Test suite reviewed monthly for relevance
- Remove tests for deprecated features immediately
- Update tests before merging feature changes (tests are part of the PR)

---

## Related Documents

- [Test Strategy](./test-strategy.md)
- [Test Plan](./test-plan.md)
- [Test Case Template](./test-case-template.md)
- [CI/CD Pipeline](../INFRASTRUCTURE/cicd-pipeline.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Approver | | | |

# Performance Test Plan

# Performance Test Plan

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Performance Testing Objectives

<!-- GUIDANCE: Performance testing validates the system meets NFRs under realistic and peak conditions. State specific, measurable objectives. -->

1. Validate that {{PROJECT_NAME}} meets the performance SLAs defined in the NFR document under normal operating conditions
2. Determine the maximum capacity the system can handle before performance degrades
3. Identify bottlenecks (database, application, infrastructure) before production release
4. Establish a performance baseline for regression comparison in future releases

**Reference NFRs:** {{NFR_DOC_LINK}} <!-- Link to non-functional requirements -->

---

## 2. Performance Requirements Reference

<!-- GUIDANCE: These are the pass/fail criteria. Every performance test must have a target it is validating. -->

| Endpoint / Feature | P50 | P90 | P95 | P99 | Error Rate | Throughput |
|-------------------|-----|-----|-----|-----|------------|------------|
| `GET /` (homepage) | < {{P50}}ms | < {{P90}}ms | < {{P95}}ms | < {{P99}}ms | < {{ERR}}% | {{RPS}} req/s |
| `POST /api/auth/login` | < {{P50}}ms | < {{P90}}ms | < {{P95}}ms | < {{P99}}ms | < {{ERR}}% | {{RPS}} req/s |
| `GET /api/{{RESOURCE}}` | < {{P50}}ms | < {{P90}}ms | < {{P95}}ms | < {{P99}}ms | < {{ERR}}% | {{RPS}} req/s |
| `POST /api/{{RESOURCE}}` | < {{P50}}ms | < {{P90}}ms | < {{P95}}ms | < {{P99}}ms | < {{ERR}}% | {{RPS}} req/s |
| Database query (P95) | < {{DB_P95}}ms | | | | | |
| Page load (First Contentful Paint) | | | < {{FCP}}ms | | | |

<!-- TODO: Add all endpoints and features that have performance requirements -->

---

## 3. Test Types

### 3.1 Load Testing — Normal Load Simulation

<!-- GUIDANCE: Simulates expected production traffic. Should run against performance SLAs. -->

**Objective:** Confirm the system meets SLAs under expected normal load
**Normal load definition:** {{NORMAL_USERS}} concurrent users / {{NORMAL_RPS}} requests/second
**Duration:** {{LOAD_DURATION}} minutes (after ramp-up)
**Pass criteria:** All SLA targets in Section 2 met with ≤ {{LOAD_ERROR_RATE}}% error rate

### 3.2 Stress Testing — Beyond Normal Capacity

<!-- GUIDANCE: Find the breaking point. Understand failure mode (graceful degradation vs hard crash). -->

**Objective:** Find the maximum capacity and understand failure behavior
**Starting point:** {{STRESS_START_USERS}} users, increasing by {{STRESS_INCREMENT}} users every {{STRESS_STEP}}min
**Stop condition:** Error rate > {{STRESS_STOP_ERROR}}% or service crashes
**Pass criteria:** System fails gracefully (circuit breakers, meaningful error messages), data integrity maintained

### 3.3 Spike Testing — Sudden Traffic Surges

<!-- GUIDANCE: Simulate viral traffic events, marketing campaigns, product launches. -->

**Objective:** Verify system handles sudden traffic spikes without crashing
**Baseline:** {{SPIKE_BASELINE}} users
**Spike to:** {{SPIKE_PEAK}} users ({{SPIKE_MULTIPLIER}}× baseline)
**Spike duration:** {{SPIKE_DURATION}} minutes
**Pass criteria:** System recovers to baseline performance within {{SPIKE_RECOVERY}} minutes after spike ends

### 3.4 Endurance / Soak Testing — Sustained Load

<!-- GUIDANCE: Finds memory leaks, connection pool exhaustion, disk fill, log file growth over time. -->

**Objective:** Identify resource leaks and degradation under sustained load
**Load level:** {{SOAK_USERS}} users ({{SOAK_PERCENT}}% of normal load)
**Duration:** {{SOAK_DURATION}} hours
**Metrics to watch:** Memory usage trend, response time trend, disk space, database connection pool
**Pass criteria:** No upward trend in memory/response time over the soak period

### 3.5 Scalability Testing — Increasing Load

<!-- GUIDANCE: Verify that adding resources (horizontal/vertical scaling) results in proportional throughput increase. -->

**Objective:** Verify linear (or better) scaling as infrastructure grows
**Test:** Step load from {{SCALE_START}} to {{SCALE_MAX}} users while scaling from {{MIN_INSTANCES}} to {{MAX_INSTANCES}} instances
**Pass criteria:** Throughput increases proportionally (≥ {{SCALE_EFFICIENCY}}% efficiency) with added instances

---

## 4. Load Profiles

<!-- GUIDANCE: Define exact load scenarios. These are the inputs to your performance test scripts. -->

| Scenario | Virtual Users | Ramp-Up | Hold | Ramp-Down | Think Time | Iterations |
|----------|-------------|---------|------|-----------|------------|------------|
| Smoke (quick sanity) | {{SMOKE_VU}} | {{SMOKE_RAMP}}s | {{SMOKE_HOLD}}min | 30s | 1s | 1 |
| Load (normal) | {{LOAD_VU}} | {{LOAD_RAMP}}min | {{LOAD_HOLD}}min | 5min | {{THINK}}s | — |
| Stress | {{STRESS_VU}} (increasing) | {{STRESS_RAMP}}min | Until failure | — | {{THINK}}s | — |
| Spike | {{SPIKE_VU}} (instant) | 0s | {{SPIKE_HOLD}}min | 0s | {{THINK}}s | — |
| Soak | {{SOAK_VU}} | {{SOAK_RAMP}}min | {{SOAK_HOLD}}h | 10min | {{THINK}}s | — |

**Think time simulation:** Random between {{THINK_MIN}}s and {{THINK_MAX}}s (realistic user behavior)

---

## 5. Test Environment

<!-- GUIDANCE: Performance tests MUST run against a production-equivalent environment. Results from under-sized environments are misleading. -->

**CRITICAL:** Performance tests run on a dedicated environment with the same infrastructure sizing as production.

| Component | Test Environment | Production |
|-----------|-----------------|------------|
| App instances | {{TEST_APP_INSTANCES}} × {{TEST_INSTANCE_TYPE}} | {{PROD_APP_INSTANCES}} × {{PROD_INSTANCE_TYPE}} |
| Database | {{TEST_DB_SPEC}} | {{PROD_DB_SPEC}} |
| Cache | {{TEST_CACHE_SPEC}} | {{PROD_CACHE_SPEC}} |
| CDN | Disabled (direct hit) | Enabled |

**Load generator infrastructure:**
- Tool: {{PERF_TOOL}} <!-- k6 / JMeter / Gatling / Locust -->
- Load generator location: {{LG_LOCATION}} (same region as app, separate VPC)
- Load generator sizing: {{LG_SPEC}}

---

## 6. Test Data Requirements

<!-- GUIDANCE: Performance tests need realistic data volume. Empty DBs produce misleading fast results. -->

| Data Type | Volume | Generation Method |
|-----------|--------|-------------------|
| Users | {{USER_COUNT}} | Script + factory |
| {{DATA_TYPE_1}} | {{VOLUME}} | Bulk import script |
| {{DATA_TYPE_2}} | {{VOLUME}} | Bulk import script |
| Search index | Production-sized | Seeded from anonymized production data |

**Database size at test time:** {{DB_SIZE}}GB
**Data preparation:** `bash scripts/perf-seed.sh` (estimated time: {{SEED_TIME}}min)

---

## 7. Tools & Infrastructure

<!-- GUIDANCE: Document the complete toolchain with versions. -->

| Tool | Version | Purpose | Config |
|------|---------|---------|--------|
| {{PERF_TOOL}} | {{VERSION}} | Load generation | `perf-tests/` |
| {{MONITOR_TOOL}} | {{VERSION}} | Real-time metrics during test | Dashboard link |
| {{APM_TOOL}} | {{VERSION}} | Application performance profiling | Dashboard link |
| {{DB_MONITOR}} | {{VERSION}} | Database query analysis | Dashboard link |

**Script location:** `{{PERF_SCRIPT_PATH}}`

---

## 8. Key Metrics to Capture

<!-- GUIDANCE: Capture all these metrics for every performance test run. -->

### Response Time

| Metric | Description | Tool |
|--------|-------------|------|
| P50 (median) | Half of requests faster than this | {{TOOL}} |
| P90 | 90% of requests faster than this | {{TOOL}} |
| P95 | 95% of requests faster than this | {{TOOL}} |
| P99 | 99% of requests faster than this | {{TOOL}} |
| Max | Worst single request | {{TOOL}} |

### Throughput

| Metric | Description |
|--------|-------------|
| Requests/second | Total throughput at peak load |
| Transactions/second | Successful business transactions/second |
| Data transferred | Total MB/s in + out |

### Error Metrics

| Metric | Target |
|--------|--------|
| HTTP error rate (5xx) | < {{HTTP_ERR}}% |
| Timeout rate | < {{TIMEOUT_ERR}}% |
| Connection refused rate | 0% |

### Resource Utilization

| Resource | Warning | Critical |
|----------|---------|---------|
| App CPU | > {{CPU_WARN}}% | > {{CPU_CRIT}}% |
| App Memory | > {{MEM_WARN}}% | > {{MEM_CRIT}}% |
| DB CPU | > {{DB_CPU_WARN}}% | > {{DB_CPU_CRIT}}% |
| DB Connections | > {{DB_CONN_WARN}}% of pool | > {{DB_CONN_CRIT}}% |
| Cache hit ratio | < {{CACHE_HIT}}% | < {{CACHE_CRIT}}% |

### Database Query Performance

| Metric | Target |
|--------|--------|
| Average query time | < {{AVG_QUERY}}ms |
| Slow queries (> {{SLOW_THRESHOLD}}ms) | < {{SLOW_COUNT}} per minute |
| Deadlocks | 0 |

---

## 9. SLA Targets Per Endpoint

<!-- GUIDANCE: Repeat from Section 2 in a format that can be directly referenced by the test scripts. -->

| Endpoint | Method | P95 SLA | Error Rate SLA | Notes |
|----------|--------|---------|----------------|-------|
| `/` | GET | {{P95}}ms | < {{ERR}}% | Static or cached |
| `/api/auth/login` | POST | {{P95}}ms | < {{ERR}}% | Auth critical path |
| `/api/{{RESOURCE}}` | GET | {{P95}}ms | < {{ERR}}% | {{NOTE}} |
| `/api/{{RESOURCE}}` | POST | {{P95}}ms | < {{ERR}}% | {{NOTE}} |

---

## 10. Baseline Establishment

<!-- GUIDANCE: A baseline is required to detect regressions in future releases. Establish it on first run. -->

**Baseline criteria:** System in stable state, seeded with production-realistic data, running load test scenario for {{BASELINE_DURATION}} minutes

**Baseline metrics to record:**

| Metric | Baseline Value | Date Recorded |
|--------|---------------|---------------|
| P95 latency (key endpoints) | TBD | {{DATE}} |
| Throughput at normal load | TBD | {{DATE}} |
| Error rate at normal load | TBD | {{DATE}} |
| CPU utilization at normal load | TBD | {{DATE}} |
| Memory utilization at normal load | TBD | {{DATE}} |

**Regression threshold:** Alert if any metric degrades > {{REGRESSION_THRESHOLD}}% vs baseline

---

## 11. Test Execution Schedule

| Run Type | Trigger | Environment | Frequency |
|----------|---------|-------------|-----------|
| Smoke | Every deployment | Staging | Per deploy |
| Load (baseline) | Release candidate | Production-sized | Per release |
| Stress | Major feature releases | Production-sized | Quarterly |
| Soak | Before major releases | Production-sized | Per release |
| Scalability | Infrastructure changes | Production-sized | As needed |

---

## 12. Results Analysis Template

<!-- GUIDANCE: Use this format to document results for every performance test run. -->

**Test Run ID:** {{RUN_ID}}
**Date:** {{DATE}}
**Tester:** {{TESTER}}
**Scenario:** {{SCENARIO}}
**Build / Version:** {{VERSION}}

| Endpoint | P50 (ms) | P90 (ms) | P95 (ms) | P99 (ms) | Error % | RPS | Status vs SLA |
|----------|----------|----------|----------|----------|---------|-----|---------------|
| {{ENDPOINT}} | — | — | — | — | — | — | ✅ Pass / ❌ Fail |

**Summary:**
- Peak concurrent users: {{PEAK_USERS}}
- Peak throughput: {{PEAK_RPS}} req/s
- Test duration: {{DURATION}} min
- Total requests: {{TOTAL_REQUESTS}}
- Total errors: {{TOTAL_ERRORS}}

**Notable findings:**
- {{FINDING_1}}
- {{FINDING_2}}

**Comparison to baseline:**
- {{COMPARISON}}

**Recommendation:** Pass / Fail / Conditional pass with {{CONDITIONS}}

---

## 13. Bottleneck Identification Process

<!-- GUIDANCE: When performance tests fail, follow this systematic process to find the root cause. -->

```
1. Check application error rate → Is the app returning errors, or just slow?
2. Check P99 vs P50 spread → Large spread = outlier requests (DB queries, locks, GC pauses)
3. Check CPU saturation → CPU > 80% sustained = compute bottleneck
4. Check memory → Memory growing during test = leak / GC pressure
5. Check DB metrics → Slow queries, high connections, deadlocks
6. Check cache hit rate → Low cache hit = DB overloaded unnecessarily
7. Check external calls → Third-party API latency or rate limiting
8. Check network → Bandwidth saturation, packet loss
```

---

## 14. Remediation Tracking

<!-- GUIDANCE: Track performance issues found and their fixes to ensure they are resolved. -->

| Issue | Found In | Severity | Root Cause | Fix | Fixed In | Verified |
|-------|----------|----------|------------|-----|----------|----------|
| {{ISSUE}} | {{SCENARIO}} | {{SEVERITY}} | {{CAUSE}} | {{FIX}} | {{VERSION}} | {{DATE}} |

---

## Related Documents

- [Test Strategy](./test-strategy.md)
- [Monitoring & Observability](../INFRASTRUCTURE/monitoring-observability.md)
- [SLA Report](../OPERATIONS/sla-report.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Approver | | | |

# Definition of Done: Drop — Fintech Payment App

# Definition of Done: Drop — Fintech Payment App

> **Project:** Drop — Remittance + QR Payments
> **Version:** 1.0
> **Date:** 2026-02-23
> **Author:** John (AI Director)
> **Status:** Approved
> **Reviewers:** Alem Bašić (CEO)

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | 2026-02-23 | John | Initial DoD — fintech-specific with pass-through model invariants |

---

## 1. Purpose

The Definition of Done (DoD) is a shared agreement across the Drop team on what must be true before any work item can be considered complete. It exists to:

- Prevent technical debt accumulation through rushed or incomplete work
- Ensure consistent quality across all team members and work types (Builder agent, Validator agent, John)
- Create a shared language for "done" that developers, QA, and Alem (CEO) all agree on
- Prevent issues from reaching production that could have been caught earlier
- Protect the pass-through model: Drop NEVER stores customer money, card numbers, or CVV data

**Enforcement:** The DoD is non-negotiable for Drop. Any exception requires explicit sign-off from John (AI Director) and must be tracked as a Mission Control task with a linked risk acceptance from Alem Bašić (CEO). Undocumented shortcuts are not acceptable in a fintech product.

---

## 2. Feature-Level DoD

When is a **feature** done?

### Code Quality
- [ ] Code is complete and implements all acceptance criteria from the AC document (`docs/BUSINESS-REQUIREMENTS/acceptance-criteria.md`)
- [ ] Code reviewed and approved by Validator agent (read-only reviewer)
- [ ] All review comments resolved or explicitly deferred with a Mission Control task
- [ ] No TODO/FIXME comments left without corresponding Mission Control tasks
- [ ] Code follows Drop coding standards — TypeScript, Next.js App Router patterns, parameterized SQL
- [ ] No unnecessary dead code added
- [ ] No `console.log` / debug statements left in production code

### Testing — Drop Specific
- [ ] Unit tests written for all new business logic (≥ 80% coverage; 100% for auth + transaction logic)
- [ ] Integration tests written for all new API endpoints (`api-endpoints.test.ts`)
- [ ] DB compliance assertions added if any schema changes (`db.test.ts` — no balance, no CVV)
- [ ] All existing tests still pass (no regressions — all 40+ Vitest tests green)
- [ ] Test coverage has not decreased below project minimum (80% overall)
- [ ] Edge cases tested: age boundary (exactly 18), amount boundaries (100 NOK min, 50,000 NOK max)
- [ ] **Pass-through invariant test**: if new DB schema changes, `db.test.ts` must assert:
  - `users` table has NO `balance` column
  - `cards` table has NO `card_number` or `cvv` columns

### Security — Drop Fintech Standards
- [ ] OWASP Top 10 reviewed for this feature (especially if touching auth or payments)
- [ ] Input validation in place for all user inputs (Zod schema — server-side)
- [ ] Authorization checks correct (JWT cookie required for all protected endpoints)
- [ ] No sensitive data logged (no passwords, no card numbers, no full JWT tokens in logs)
- [ ] No sensitive data in API responses (no password hashes, no full card numbers)
- [ ] Rate limiting applies to new endpoints if they handle auth or financial actions
- [ ] CSRF token required on all new POST/PATCH/DELETE endpoints
- [ ] Parameterized SQL only — no string concatenation in DB queries
- [ ] `npm audit` passes — no new HIGH/CRITICAL CVEs introduced

### Performance
- [ ] Performance budget met — no P95 regression > 15% vs baseline (api-benchmarks.test.ts)
- [ ] No N+1 query problems (each API call makes a bounded number of DB queries)
- [ ] bcrypt timing within 1,000ms P95 (after registration/login changes)
- [ ] No synchronous heavy operations blocking the event loop

### Documentation
- [ ] Code is self-documenting or has inline comments for non-obvious Drop business logic
- [ ] API reference updated if new endpoints added (`docs/backend/API-REFERENCE.md`)
- [ ] Architecture Decision Record created for significant architectural choices (e.g., pass-through model changes)
- [ ] CLAUDE.md or relevant project docs updated if dev workflow changes

### API (if applicable)
- [ ] API documentation updated (`docs/backend/API-REFERENCE.md`)
- [ ] Breaking changes explicitly documented in release notes
- [ ] Response schema consistent with existing patterns (error format, HTTP status codes)

### Error Handling
- [ ] All error conditions handled gracefully (no unhandled promise rejections)
- [ ] Error messages are user-friendly and in Norwegian where applicable
- [ ] No stack traces in production API responses
- [ ] External service failures handled (mock BaaS timeout → user-friendly error)
- [ ] Financial errors use correct HTTP status codes (402 Insufficient Balance; 403 KYC Required)

### Compliance Checklist (Drop-specific — MANDATORY)
- [ ] **PCI-DSS**: No `card_number` or `cvv` stored or returned in full
- [ ] **Pass-through model (ADR-003)**: No `balance` column added to users table
- [ ] **AML**: Transaction amounts ≤ 50,000 NOK enforced
- [ ] **Age verification**: Age ≥ 18 validation in place for any new user-facing flows
- [ ] **Audit trail**: New financial events logged in `audit_logs` table

### Deployment
- [ ] Deployed to staging (https://drop-staging.fly.dev/) and manually verified
- [ ] Database migrations tested on staging (up and down migrations)
- [ ] Environment variables documented in `docs/DEVELOPER-EXPERIENCE/local-development-setup.md`
- [ ] Feature flag configured if the feature is gated (e.g., Cards, BankID)
- [ ] John (AI Director) has reviewed and accepted the feature in staging

---

## 3. Sprint-Level DoD

When is a **sprint** done?

- [ ] All committed Mission Control tasks meet their individual Definition of Done
- [ ] All automated tests passing in CI (Vitest: 40+ tests; Playwright: 3 projects)
- [ ] Staging environment is stable (no broken features on https://drop-staging.fly.dev/)
- [ ] Technical debt created during the sprint is tracked in Mission Control backlog
- [ ] Sprint review conducted — John (AI Director) and Alem (CEO if available) have seen deliverables
- [ ] Retrospective findings logged in `docs/CROSS-CUTTING/lessons-learned.md`
- [ ] Next sprint's tasks refined and priority-ordered in Mission Control

---

## 4. Release-Level DoD

When is a **release** done?

- [ ] All features in scope meet the Feature-Level DoD
- [ ] Full regression test suite passing on staging (all 26 API routes via `api-endpoints.test.ts`)
- [ ] Playwright E2E tests passing for all 5 critical journeys (user-flows, full-flows, input-chaos)
- [ ] Performance benchmarks passing — all NFR-P01..P06 targets met (`api-benchmarks.test.ts`)
- [ ] Security scan complete — no unresolved HIGH/CRITICAL findings (`npm audit` clean)
- [ ] DB compliance tests passing — `db.test.ts` all assertions green (no balance, no CVV)
- [ ] UAT conducted with Alem Bašić (CEO) sign-off (or documented conditional approval)
- [ ] Release notes written: `docs/RELEASE/release-notes.md`
- [ ] Deployment checklist complete: `docs/RELEASE/deployment-checklist.md`
- [ ] Rollback plan prepared and tested: `docs/RELEASE/rollback-plan.md`
- [ ] John (AI Director) briefed on all changes and potential failure modes
- [ ] Security audit score ≥ 80/100 (Phase 0.5 requirement)

---

## 5. Bug Fix DoD

When is a **bug fix** done?

- [ ] Root cause understood and documented in the Mission Control task
- [ ] Fix addresses root cause (not just symptoms)
- [ ] Unit/integration test written that would have caught this bug (regression test added)
- [ ] Fix does not introduce new failures (all 40+ tests still passing)
- [ ] Fix verified in staging environment
- [ ] Related areas spot-checked for similar issues
- [ ] Mission Control task updated with root cause and resolution notes
- [ ] `docs/CROSS-CUTTING/lessons-learned.md` updated if the bug reveals a systemic pattern

---

## 6. Hotfix DoD

When is a **hotfix** done?

- [ ] Fix verified locally and on staging (cannot skip staging — even for hotfixes)
- [ ] Validator agent has reviewed the fix (at minimum async review)
- [ ] Smoke tests passing post-deployment (Playwright user-flows project)
- [ ] Mission Control incident task updated with fix details
- [ ] Full regression test run scheduled within 4 hours
- [ ] Post-mortem scheduled within 24 hours if P1/P2 severity (DORA compliance)
- [ ] Rollback plan confirmed (Fly.io rollback ready in case hotfix causes regression)

---

## 7. Drop-Specific Additions

### Pass-Through Model Invariant (Non-Negotiable)

The following assertions must pass on **every commit** — they are not optional:

```typescript
// db.test.ts assertions — NEVER disable these:
expect(columns).not.toContain('balance')       // users table
expect(columns).not.toContain('card_number')   // cards table
expect(columns).not.toContain('cvv')           // cards table
```

If these tests fail, the build fails. No exceptions. No PR merges until fixed.

### Financial Calculation Verification

All fee changes (currently 0.5% remittance, 1% QR) must include:
1. Unit test in `transactions.test.ts` verifying exact fee amount
2. Boundary test at minimum amount (100 NOK) and maximum amount (50,000 NOK)
3. A comment in the code referencing the business rule (BRD section)

### Norwegian Language Compliance

User-facing error messages for age validation must include Norwegian text:
- Age rejection: "Du må være minst 18 år"
- Other messages: Norwegian primary, English secondary
- Check: Playwright input-chaos.spec.ts includes Norwegian error message assertions

---

## Related Documents

- [Test Strategy](./test-strategy.md)
- [Coding Standards](../DEVELOPER-EXPERIENCE/coding-standards.md)
- [Deployment Checklist](../RELEASE/deployment-checklist.md)
- [UAT Sign-off](../RELEASE/uat-signoff.md)
- [Acceptance Criteria](../BUSINESS-REQUIREMENTS/acceptance-criteria.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | John (AI Director) | 2026-02-23 | Approved (AI) |
| QA Lead | Validator Agent | 2026-02-23 | Approved (AI) |
| Tech Lead | John | 2026-02-23 | Approved |
| CEO (Alem) | Alem Bašić | TBD | |

# Test Strategy

# Test Strategy

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Testing Philosophy & Principles

<!-- GUIDANCE: Articulate the team's values around testing. This sets expectations for all developers. -->

**Core Principles:**
1. **Tests are first-class code** — reviewed, maintained, refactored like production code
2. **Test the behavior, not the implementation** — tests enable safe refactoring
3. **Fast feedback** — unit tests run in seconds; blocking tests run in < 5 minutes
4. **Tests document intent** — a failing test explains what broke and why it matters
5. **Shift left** — find bugs as early as possible, before they reach users

**Testing philosophy:** {{PHILOSOPHY}}
<!-- e.g., "We follow the test pyramid — heavy unit test coverage supplemented by targeted integration and E2E tests for critical paths. We do not aim for 100% E2E coverage; instead we validate the most valuable user journeys." -->

---

## 2. Test Pyramid

<!-- GUIDANCE: Customize the percentages and descriptions for your project. -->

```mermaid
pyramid
    title Test Distribution
    accTitle: Test Distribution by Layer
    "Unit Tests (70%)" : 70
    "Integration Tests (20%)" : 20
    "E2E Tests (10%)" : 10
```

```mermaid
graph TB
    subgraph E2E["E2E Tests — 10%"]
        E2E_DESC["Critical user journeys<br/>Browser / API end-to-end<br/>Slow, expensive, high-confidence"]
    end
    subgraph INT["Integration Tests — 20%"]
        INT_DESC["Service-to-service<br/>DB + cache + external APIs<br/>Medium speed, high-value"]
    end
    subgraph UNIT["Unit Tests — 70%"]
        UNIT_DESC["Functions, classes, modules<br/>Pure business logic<br/>Fast, cheap, developer-owned"]
    end
```

### 2.1 Unit Tests

<!-- GUIDANCE: Define scope clearly. What qualifies as a unit? How do you handle external dependencies? -->

| Attribute | Value |
|-----------|-------|
| **Scope** | Individual functions, classes, pure business logic |
| **External dependencies** | Mocked (no real DB, network, or filesystem calls) |
| **Framework** | {{UNIT_FRAMEWORK}} <!-- Jest / Vitest / pytest / JUnit / RSpec --> |
| **Coverage target** | ≥ {{UNIT_COVERAGE}}% lines, ≥ {{BRANCH_COVERAGE}}% branches |
| **Execution time** | Full suite < {{UNIT_TIME}} minutes |
| **Runs on** | Every commit, pre-commit hook |
| **Written by** | Developer who writes the feature |

**What to unit test:**
- Business logic and algorithms
- Edge cases and error conditions
- Data transformations and validations
- Utility functions

**What NOT to unit test:**
- Third-party library internals
- Simple property getters/setters with no logic
- Framework boilerplate

### 2.2 Integration Tests

| Attribute | Value |
|-----------|-------|
| **Scope** | Service interactions: DB, cache, message queues, internal APIs |
| **External dependencies** | Real (test containers or shared test environment) |
| **Framework** | {{INT_FRAMEWORK}} |
| **Coverage target** | All service boundaries tested; ≥ {{INT_COVERAGE}}% of integration paths |
| **Execution time** | Full suite < {{INT_TIME}} minutes |
| **Runs on** | Every PR, blocking merge |
| **Written by** | Developer who writes the integration |

**What to integration test:**
- Database queries and ORM mappings
- API endpoint request/response contracts
- Message queue publish/consume
- Cache read/write behavior
- Authentication middleware

### 2.3 E2E Tests

| Attribute | Value |
|-----------|-------|
| **Scope** | Critical user journeys through the real deployed application |
| **External dependencies** | Real (staging environment) |
| **Framework** | {{E2E_FRAMEWORK}} <!-- Playwright / Cypress --> |
| **Coverage target** | Top {{E2E_JOURNEY_COUNT}} critical user journeys |
| **Execution time** | Full suite < {{E2E_TIME}} minutes |
| **Runs on** | Post-staging deploy, pre-production gate |
| **Written by** | QA + Developer collaboration |

**Critical journeys to E2E test:**
1. {{JOURNEY_1}} <!-- e.g., User registration + email verification + first login -->
2. {{JOURNEY_2}} <!-- e.g., Product discovery → add to cart → checkout → confirmation -->
3. {{JOURNEY_3}}
<!-- TODO: Complete list based on business-critical paths -->

---

## 3. Testing Tools

<!-- GUIDANCE: Pin tool versions to prevent unexpected CI failures from version changes. -->

| Type | Tool | Version | Purpose | Config File |
|------|------|---------|---------|-------------|
| Unit testing | {{UNIT_TOOL}} | {{VERSION}} | Unit tests | `{{CONFIG_PATH}}` |
| Test runner | {{RUNNER}} | {{VERSION}} | Parallel execution | `{{CONFIG_PATH}}` |
| Mocking | {{MOCK_TOOL}} | {{VERSION}} | Mock external deps | Built-in |
| Integration testing | {{INT_TOOL}} | {{VERSION}} | Integration tests | `{{CONFIG_PATH}}` |
| Test containers | {{CONTAINER_TOOL}} | {{VERSION}} | Real DB/Redis in tests | `{{CONFIG_PATH}}` |
| E2E testing | {{E2E_TOOL}} | {{VERSION}} | Browser E2E | `{{CONFIG_PATH}}` |
| Coverage | {{COV_TOOL}} | {{VERSION}} | Coverage reports | `{{CONFIG_PATH}}` |
| Performance testing | {{PERF_TOOL}} | {{VERSION}} | Load/stress tests | `{{CONFIG_PATH}}` |
| Visual regression | {{VIS_TOOL}} | {{VERSION}} | UI screenshot diff | `{{CONFIG_PATH}}` |

---

## 4. Test Environments & Data Management

### Test Environments

| Test Type | Environment | Database | External Services |
|-----------|-------------|----------|------------------|
| Unit | Local (no env) | None / in-memory | Mocked |
| Integration | Local + Docker | TestContainers | Stubbed |
| E2E | Staging | Dedicated test DB | Sandbox/test mode |
| Performance | Staging (production-sized) | Production-scale data | Sandbox |

### Test Data Management

<!-- GUIDANCE: Define how test data is created, isolated, and cleaned up. -->

| Approach | Used For | Tool | Notes |
|----------|----------|------|-------|
| Fixtures / factories | Unit + integration tests | {{FACTORY_TOOL}} | Reset per test |
| Database seeding | E2E tests | `scripts/seed.sh` | Reset per test run |
| Anonymized production data | Performance tests | `scripts/anonymize.sh` | Weekly refresh |
| Shared test accounts | E2E (cross-service) | Test account vault | Never modified by tests |

**Data cleanup policy:** All test data cleaned up after test run (via teardown hooks or transaction rollback)

---

## 5. Test Automation Strategy

<!-- GUIDANCE: Define what is automated vs manual. Automation should be the default. -->

| Test Type | Automation | Trigger | Tooling |
|-----------|------------|---------|---------|
| Unit tests | 100% automated | Pre-commit + CI | {{UNIT_TOOL}} |
| Integration tests | 100% automated | CI on PR | {{INT_TOOL}} |
| E2E (critical paths) | 100% automated | Post-staging deploy | {{E2E_TOOL}} |
| E2E (edge cases) | Partially automated | Weekly scheduled run | {{E2E_TOOL}} |
| Performance tests | Automated baseline | Weekly + pre-release | {{PERF_TOOL}} |
| Security (SAST/SCA) | 100% automated | Every PR | {{SAST_TOOL}} |
| Visual regression | Automated | On UI changes | {{VIS_TOOL}} |
| Accessibility | Automated + manual | On UI changes | {{A11Y_TOOL}} |
| Manual exploratory | Manual | Sprint end / pre-release | — |

---

## 6. Manual Testing Scope

<!-- GUIDANCE: Not everything should be automated. Define what requires human judgment. -->

**Manual testing is required for:**
- New feature exploratory testing (first sprint of a feature)
- Usability and UX review
- Accessibility testing (beyond automated checks)
- Complex multi-step business scenarios not yet automated
- Third-party integrations with limited test environments
- Devices/browsers outside automated matrix

**Manual testing is NOT required for:**
- Regression of previously tested features (automate these)
- CRUD operations on standard forms
- Unit-level logic covered by automated tests

---

## 7. Code Coverage Requirements

<!-- GUIDANCE: Coverage is a proxy metric, not a goal. Set minimums that encourage meaningful tests. -->

| Layer | Lines | Branches | Functions | Notes |
|-------|-------|----------|-----------|-------|
| Business logic | ≥ {{BIZ_COV}}% | ≥ {{BIZ_BRANCH}}% | ≥ {{BIZ_FN}}% | Strictly enforced |
| API handlers | ≥ {{API_COV}}% | ≥ {{API_BRANCH}}% | ≥ {{API_FN}}% | |
| Utilities | ≥ {{UTIL_COV}}% | ≥ {{UTIL_BRANCH}}% | ≥ {{UTIL_FN}}% | |
| UI components | ≥ {{UI_COV}}% | — | ≥ {{UI_FN}}% | Render + interaction |
| **Overall minimum** | **≥ {{TOTAL_COV}}%** | — | — | CI gate |

**Coverage enforcement:** CI pipeline fails if coverage drops below minimum
**Coverage report:** Published to {{COV_REPORT_URL}} on every PR

---

## 8. Quality Gates

<!-- GUIDANCE: These are the must-pass checks before code can be merged or deployed. -->

### PR Merge Gate (must pass before merge)
- [ ] All unit tests pass
- [ ] All integration tests pass
- [ ] Coverage ≥ minimum thresholds
- [ ] No HIGH/CRITICAL security findings (SAST/SCA)
- [ ] No secrets detected
- [ ] Linting passes
- [ ] Type checking passes (if typed language)

### Staging Deploy Gate (must pass before staging deploy)
- [ ] All PR gates passed
- [ ] Build artifact created and signed

### Production Deploy Gate (must pass before production deploy)
- [ ] All E2E tests pass on staging
- [ ] Performance baseline not degraded > {{PERF_REGRESSION}}%
- [ ] Manual QA sign-off (if sprint includes new features)
- [ ] Manual approval in CI pipeline

---

## 9. Responsibility Matrix

<!-- GUIDANCE: Clarity on ownership prevents testing gaps. -->

| Test Type | Writes Tests | Reviews Tests | Maintains Tests | Signs Off |
|-----------|-------------|---------------|-----------------|-----------|
| Unit tests | Developer | PR reviewer | Developer | Tech lead |
| Integration tests | Developer | QA engineer | Developer | Tech lead |
| E2E tests | QA + Developer | Tech lead | QA engineer | QA lead |
| Performance tests | DevOps + Developer | Tech lead | DevOps | Eng manager |
| Security tests | DevOps (automated) | Security | DevOps | Security lead |

---

## 10. Test Reporting & Metrics

<!-- GUIDANCE: Measure test health to prevent debt accumulation. -->

| Metric | Target | Reporting |
|--------|--------|-----------|
| Test pass rate | ≥ 99% (unit), ≥ 95% (E2E) | CI dashboard |
| Flaky test rate | < {{FLAKY_RATE}}% | Weekly report |
| Test execution time | < {{TOTAL_TEST_TIME}} min (full suite) | CI dashboard |
| Coverage trend | Stable or improving | PR comments |
| Tests added per sprint | ≥ {{TESTS_PER_SPRINT}} | Sprint metrics |

---

## 11. Continuous Testing in CI/CD

<!-- GUIDANCE: Summarize how testing integrates into the pipeline. Reference cicd-pipeline.md for details. -->

See [CI/CD Pipeline](../INFRASTRUCTURE/cicd-pipeline.md) for full pipeline details.

| Stage | Tests Run | Blocking |
|-------|-----------|---------|
| Pre-commit (local) | Unit tests, linting | Yes (can be bypassed with `--no-verify` with justification) |
| PR open / update | Unit + integration + SAST + SCA | Yes — blocks merge |
| Staging deploy | E2E, visual regression | Yes — blocks production |
| Production deploy | Smoke tests, monitoring check | Yes — auto-rollback on failure |
| Scheduled (nightly) | Full E2E suite, performance baseline | No — alerts only |

---

## Related Documents

- [Test Plan](./test-plan.md)
- [E2E Test Plan](./e2e-test-plan.md)
- [Performance Test Plan](./performance-test-plan.md)
- [Definition of Done](./definition-of-done.md)
- [CI/CD Pipeline](../INFRASTRUCTURE/cicd-pipeline.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Approver | | | |

# Test Plan

# Test Plan

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Test Objectives

<!-- GUIDANCE: State what this specific test plan aims to verify. These should map to acceptance criteria from the requirements doc. -->

This test plan covers testing for **{{RELEASE_NAME}}** ({{VERSION}}) of {{PROJECT_NAME}}.

**Primary objectives:**
1. Verify that {{OBJECTIVE_1}} <!-- e.g., "the new checkout flow handles all payment methods correctly" -->
2. Verify that {{OBJECTIVE_2}}
3. Confirm no regression in {{REGRESSION_AREA}}
4. Validate performance under expected production load

**Out of scope for this plan:** See Section 3 (Scope).

---

## 2. Features Under Test

<!-- GUIDANCE: List all features/user stories that must be tested in this release. -->

| Feature / Story | Priority | Test Types | Owner |
|-----------------|----------|------------|-------|
| {{FEATURE_1}} | Critical | Unit, Integration, E2E | {{OWNER}} |
| {{FEATURE_2}} | High | Unit, Integration | {{OWNER}} |
| {{FEATURE_3}} | Medium | Unit | {{OWNER}} |
| Regression — {{AREA}} | High | E2E, Manual | {{OWNER}} |

<!-- TODO: Complete feature list from sprint board / release notes -->

---

## 3. Scope

### In Scope

<!-- GUIDANCE: Be specific. "Feature X including edge cases Y and Z." -->

- {{IN_SCOPE_1}}
- {{IN_SCOPE_2}}
- Regression testing of {{REGRESSION_MODULES}}
- Performance testing of {{PERF_SCOPE}} endpoints
- Security testing of new authentication changes

### Out of Scope

<!-- GUIDANCE: Explicitly stating out-of-scope prevents scope creep and misalignment. Always include justification. -->

| Item | Justification |
|------|---------------|
| {{OUT_1}} | {{REASON_1}} <!-- e.g., "No changes in this release" --> |
| {{OUT_2}} | {{REASON_2}} <!-- e.g., "Covered by separate security audit" --> |
| Third-party integrations ({{SERVICE}}) | Tested in integration test suite; provider responsible for own reliability |

---

## 4. Test Schedule & Milestones

<!-- GUIDANCE: Align test schedule with sprint/release milestones. Buffer for bug fixing. -->

| Milestone | Date | Responsible |
|-----------|------|-------------|
| Test plan approved | {{DATE}} | QA Lead |
| Test environment ready | {{DATE}} | Platform team |
| Test data seeded | {{DATE}} | QA team |
| Unit + integration tests complete | {{DATE}} | Dev team |
| E2E test authoring complete | {{DATE}} | QA team |
| Regression testing complete | {{DATE}} | QA team |
| UAT start | {{DATE}} | QA + Product |
| UAT sign-off | {{DATE}} | Product Owner |
| Performance testing complete | {{DATE}} | DevOps + QA |
| Go/no-go decision | {{DATE}} | Eng manager |
| Production release | {{DATE}} | Release manager |

---

## 5. Resource Allocation

<!-- GUIDANCE: Who is responsible for what testing activity? -->

| Resource | Role | Testing Activities | Availability |
|----------|------|-------------------|-------------|
| {{PERSON_1}} | QA Lead | E2E authoring, regression | 100% |
| {{PERSON_2}} | Developer | Unit + integration tests | 30% of sprint |
| {{PERSON_3}} | Developer | Unit + integration tests | 30% of sprint |
| {{PERSON_4}} | DevOps | Performance, infrastructure | 20% |
| {{PERSON_5}} | Product Owner | UAT review and sign-off | As needed |

---

## 6. Entry Criteria

<!-- GUIDANCE: Testing should not start until these conditions are met. Prevents wasted testing effort on unstable builds. -->

Testing may begin when:
- [ ] Feature development is code-complete (all tickets in "Ready for QA")
- [ ] Unit tests passing (≥ {{UNIT_PASS_RATE}}% pass rate)
- [ ] Integration tests passing
- [ ] Build artifact deployed to test environment
- [ ] Test environment is stable (health checks passing)
- [ ] Test data is seeded and verified
- [ ] Test cases for new features reviewed and approved
- [ ] Previous known blocking bugs resolved (see bug tracker)

---

## 7. Exit Criteria

<!-- GUIDANCE: Define "done" for testing. These conditions must be met before releasing. -->

Testing is complete when:
- [ ] All test cases executed
- [ ] ≥ {{PASS_RATE}}% of test cases pass
- [ ] All Critical and High defects resolved or accepted with justification
- [ ] Medium defects reviewed — plan in place for outstanding items
- [ ] Code coverage ≥ {{COVERAGE_GATE}}%
- [ ] E2E tests passing on staging
- [ ] Performance tests meeting SLA targets
- [ ] UAT sign-off obtained from Product Owner
- [ ] Go/no-go checklist complete (see Section 14)
- [ ] Release notes updated with test summary

**Exceptional circumstances:** If exit criteria cannot be met, a documented risk acceptance from {{ACCEPTANCE_AUTHORITY}} is required.

---

## 8. Test Strategy Summary Per Type

<!-- GUIDANCE: Brief summary for each test type being executed. Reference test strategy doc for full detail. -->

| Type | Approach | Tool | Owner | Gate |
|------|----------|------|-------|------|
| Unit | White-box, TDD where applicable | {{UNIT_TOOL}} | Developers | Blocks merge |
| Integration | Real dependencies via TestContainers | {{INT_TOOL}} | Developers | Blocks merge |
| E2E | Critical user journeys, automated | {{E2E_TOOL}} | QA | Blocks release |
| Regression | Automated suite + targeted manual | {{E2E_TOOL}} + manual | QA | Blocks release |
| Performance | Load test at {{LOAD_PROFILE}} | {{PERF_TOOL}} | DevOps | Blocks release |
| Security | SAST + SCA + manual review | {{SAST_TOOL}} | DevOps | Blocks merge |
| UAT | Business scenario validation | Manual | Product Owner | Blocks release |
| Accessibility | Automated + manual audit | {{A11Y_TOOL}} | Developer + QA | Warning |

---

## 9. Test Environment Requirements

<!-- GUIDANCE: Specify what is needed for testing. Platform team should provision before testing starts. -->

| Environment | Purpose | URL | Access Needed |
|-------------|---------|-----|---------------|
| Dev | Unit/integration | `dev.{{DOMAIN}}` | All team members |
| Staging | E2E, regression, UAT | `staging.{{DOMAIN}}` | Team + PM + stakeholders |
| Performance | Load testing | Isolated (production-sized) | DevOps + QA |

**Environment requirements:**
- Staging must have production-equivalent configuration
- Test database seeded with {{DATA_VOLUME}} records
- Third-party integrations in sandbox/test mode
- Monitoring enabled (same as production)

---

## 10. Test Data Requirements

<!-- GUIDANCE: What data must exist before testing can begin? -->

| Data Category | Volume | Creation Method | Responsible |
|---------------|--------|----------------|-------------|
| Test user accounts | {{USER_COUNT}} | `scripts/seed-users.sh` | QA team |
| {{DATA_TYPE_1}} | {{VOLUME}} | Factory / fixtures | QA team |
| {{DATA_TYPE_2}} | {{VOLUME}} | Anonymized from production | DevOps |
| Edge case data (empty states, max values) | Defined per test | Manual / fixtures | QA team |

**Data cleanup:** All test data removed after test run via `scripts/cleanup.sh`

---

## 11. Risk-Based Test Prioritization

<!-- GUIDANCE: Focus testing effort on high-impact / high-probability risk areas. -->

| Risk Area | Likelihood | Impact | Priority | Mitigation |
|-----------|------------|--------|----------|------------|
| Payment processing failure | Medium | Critical | P1 | Full regression + manual testing |
| Data migration errors | High | Critical | P1 | Staged migration + rollback plan |
| Performance degradation | Medium | High | P2 | Load test at 2x expected peak |
| Third-party API downtime | Low | Medium | P3 | Stub in tests, circuit breaker in code |
| Authentication edge cases | Low | Critical | P1 | Full auth test suite |

---

## 12. Dependencies & Assumptions

<!-- GUIDANCE: Document what must be true for testing to proceed as planned. -->

**Dependencies:**
- Platform team provisions staging environment by {{DATE}}
- {{THIRD_PARTY}} sandbox environment available
- Security team approves SAST configuration by {{DATE}}

**Assumptions:**
- Feature requirements will not change during the testing phase
- All developers will respond to bugs within {{BUG_RESPONSE_SLA}} hours
- UAT participants are available per the schedule in Section 4

---

## 13. Defect Management Process

<!-- GUIDANCE: How are bugs tracked, prioritized, and resolved? -->

**Bug tracker:** {{BUG_TRACKER}} <!-- Jira / Linear / GitHub Issues -->
**Severity levels:**

| Severity | Definition | Resolution SLA |
|----------|------------|----------------|
| Critical | System unusable, data loss, security issue | Fix before release |
| High | Major feature broken, no workaround | Fix before release |
| Medium | Feature degraded, workaround exists | Fix in next sprint |
| Low | Minor issue, cosmetic | Backlog |

**Bug lifecycle:** Open → Assigned → In Progress → Fixed → Verified → Closed
**Triage cadence:** Daily during active testing phase

---

## 14. Test Deliverables

<!-- GUIDANCE: List everything that will be produced by the testing effort. -->

| Deliverable | Format | Due Date | Owner |
|-------------|--------|----------|-------|
| Test plan (this document) | Markdown | {{DATE}} | QA Lead |
| Test cases | {{BUG_TRACKER}} / Markdown | {{DATE}} | QA team |
| Test execution results | Automated CI reports + summary | {{DATE}} | QA team |
| Defect report | {{BUG_TRACKER}} | Ongoing | QA team |
| Performance test report | Markdown + charts | {{DATE}} | DevOps |
| UAT sign-off | Signed [uat-signoff.md](../RELEASE/uat-signoff.md) | {{DATE}} | Product Owner |
| Test summary report | Markdown | {{DATE}} | QA Lead |

---

## Related Documents

- [Test Strategy](./test-strategy.md)
- [Test Case Template](./test-case-template.md)
- [E2E Test Plan](./e2e-test-plan.md)
- [Performance Test Plan](./performance-test-plan.md)
- [Definition of Done](./definition-of-done.md)
- [UAT Sign-off](../RELEASE/uat-signoff.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Approver | | | |

# Test Case Template

# Test Case Template

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Test Case ID Format & Naming Convention

<!-- GUIDANCE: A consistent ID format enables tracing from requirements to tests to defects. -->

**Format:** `TC-{{MODULE_CODE}}-{{SEQUENCE}}`

| Part | Description | Example |
|------|-------------|---------|
| `TC` | Test Case prefix (always TC) | `TC` |
| `MODULE_CODE` | 2-4 letter module abbreviation | `AUTH`, `CART`, `PAY`, `USR` |
| `SEQUENCE` | 3-digit zero-padded number | `001`, `042`, `100` |

**Examples:**
- `TC-AUTH-001` — Authentication module, first test case
- `TC-PAY-015` — Payment module, 15th test case
- `TC-CART-003` — Shopping cart module, 3rd test case

**Related requirement ID:** Link to `REQ-{{ID}}` or user story `{{TICKET_ID}}`

---

## 2. Test Suite Organization

<!-- GUIDANCE: Group test cases into suites by feature/module for easy execution and reporting. -->

| Suite ID | Suite Name | Module | Test Cases | Owner |
|----------|------------|--------|------------|-------|
| TS-AUTH | Authentication | Auth module | TC-AUTH-001 to TC-AUTH-XXX | {{OWNER}} |
| TS-CART | Shopping Cart | Cart module | TC-CART-001 to TC-CART-XXX | {{OWNER}} |
| TS-PAY | Payment Processing | Payment module | TC-PAY-001 to TC-PAY-XXX | {{OWNER}} |
| TS-SMOKE | Smoke Tests | All critical paths | TC-SMK-001 to TC-SMK-XXX | {{OWNER}} |
| TS-REG | Regression Suite | Full application | All high-priority TCs | {{OWNER}} |

<!-- TODO: Add all test suites for this project -->

---

## 3. Individual Test Case Format

<!-- GUIDANCE: Copy this template block for each test case. Fill in all required fields. -->

---

### Test Case: TC-{{MODULE}}-{{SEQ}}

| Field | Value |
|-------|-------|
| **ID** | TC-{{MODULE}}-{{SEQ}} |
| **Title** | {{CONCISE_DESCRIPTION}} <!-- e.g., "User can log in with valid credentials" --> |
| **Description** | {{FULL_DESCRIPTION}} <!-- 1-3 sentences explaining what is being verified and why --> |
| **Module / Feature** | {{MODULE_NAME}} |
| **Priority** | {{PRIORITY}} <!-- Critical / High / Medium / Low --> |
| **Type** | {{TYPE}} <!-- Functional / Regression / Smoke / Boundary / Negative / Performance --> |
| **Requirement** | {{REQ_ID}} / {{STORY_ID}} |
| **Automation Status** | {{STATUS}} <!-- Automated / Manual / Planned --> |
| **Automation ID** | {{AUTOMATION_ID}} <!-- e.g., test file path + test name, if automated --> |

#### Preconditions

<!-- GUIDANCE: State exactly what must be true before this test can be executed. -->

1. {{PRECONDITION_1}} <!-- e.g., "User account exists with email test@example.com" -->
2. {{PRECONDITION_2}} <!-- e.g., "User is not currently logged in" -->
3. {{PRECONDITION_3}}

#### Test Data

<!-- GUIDANCE: Specify exactly what data is needed. Never use real personal data. -->

| Field | Value | Notes |
|-------|-------|-------|
| Email | `{{TEST_EMAIL}}` | Test account, pre-created |
| Password | `{{TEST_PASSWORD}}` | Stored in test vault |
| {{DATA_FIELD}} | `{{VALUE}}` | {{NOTE}} |

#### Test Steps

<!-- GUIDANCE: Steps must be precise enough that any team member can execute them without asking questions. -->

| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | {{ACTION_1}} <!-- e.g., "Navigate to /login" --> | {{EXPECTED_1}} <!-- e.g., "Login form displayed with email and password fields" --> |
| 2 | {{ACTION_2}} <!-- e.g., "Enter email: test@example.com" --> | {{EXPECTED_2}} <!-- e.g., "Email entered in field" --> |
| 3 | {{ACTION_3}} | {{EXPECTED_3}} |
| 4 | {{ACTION_4}} | {{EXPECTED_4}} |

#### Expected Final Result

<!-- GUIDANCE: The overall pass condition — what success looks like after all steps are executed. -->

{{OVERALL_EXPECTED_RESULT}}
<!-- e.g., "User is logged in, redirected to /dashboard, sees 'Welcome, {{NAME}}' message, JWT cookie set" -->

#### Post-conditions

<!-- GUIDANCE: What state should the system be in after this test, whether it passes or fails? -->

- {{POSTCONDITION_1}} <!-- e.g., "Login audit log entry created" -->
- {{POSTCONDITION_2}} <!-- e.g., "Test account session invalidated (cleanup)" -->

#### Notes / Edge Cases

<!-- GUIDANCE: Any additional context, known issues, or related test cases. -->

- {{NOTE_1}}
- Related: TC-{{RELATED_ID}}

---

## 4. Priority Definitions

<!-- GUIDANCE: Use consistent priority definitions across all test cases. -->

| Priority | Definition | Examples |
|----------|------------|----------|
| **Critical** | Core functionality; system unusable without it | Login, payment, data persistence |
| **High** | Important feature; significant user impact if broken | Search, notifications, user profile |
| **Medium** | Standard feature; workaround exists | Export, advanced filters, preferences |
| **Low** | Minor feature, cosmetic, or edge case | Tooltips, sorting preferences, animations |

---

## 5. Test Case Type Definitions

| Type | Description |
|------|-------------|
| **Functional** | Verifies a feature works as specified |
| **Regression** | Verifies previously working functionality still works |
| **Smoke** | Fast check of most critical paths (subset for quick confidence) |
| **Boundary** | Tests at the edges of valid input (min, max, empty) |
| **Negative** | Tests invalid input, error conditions, unauthorized access |
| **Performance** | Verifies response time, throughput under defined load |
| **Security** | Verifies access controls, injection resistance, auth |
| **Accessibility** | Verifies WCAG compliance, keyboard navigation, screen readers |

---

## 6. Batch Test Execution Template

<!-- GUIDANCE: Use this table during a planned test execution cycle. -->

**Test Run:** {{RUN_ID}}
**Environment:** {{ENVIRONMENT}}
**Build / Version:** {{VERSION}}
**Tester:** {{TESTER}}
**Date:** {{DATE}}

| Test Case ID | Title | Priority | Result | Actual Result / Notes | Defect ID |
|-------------|-------|----------|--------|-----------------------|-----------|
| TC-{{MODULE}}-001 | {{TITLE}} | Critical | Pass / Fail / Blocked / Skip | {{NOTES}} | {{DEFECT_ID}} |
| TC-{{MODULE}}-002 | {{TITLE}} | High | | | |

**Summary:**
- Total: {{TOTAL}}
- Passed: {{PASSED}}
- Failed: {{FAILED}}
- Blocked: {{BLOCKED}}
- Skipped: {{SKIPPED}}
- Pass rate: {{PASS_RATE}}%

---

## 7. Test Execution Log Format

<!-- GUIDANCE: Maintain a log for audit purposes and to track execution progress. -->

| Timestamp | Test Case ID | Tester | Environment | Build | Result | Duration | Notes |
|-----------|-------------|--------|-------------|-------|--------|----------|-------|
| {{TIMESTAMP}} | TC-{{MODULE}}-{{SEQ}} | {{TESTER}} | staging | {{BUILD}} | Pass | {{DURATION}}s | |

---

## 8. Defect Linking

<!-- GUIDANCE: Every failed test case must link to a defect ticket. -->

**Defect format:** `BUG-{{ID}}` (in {{BUG_TRACKER}})

| Test Case | Defect ID | Severity | Status | Fixed In |
|-----------|-----------|----------|--------|----------|
| TC-{{MODULE}}-{{SEQ}} | BUG-{{ID}} | {{SEVERITY}} | {{STATUS}} | {{VERSION}} |

**Defect fields required:**
- Steps to reproduce (reference test case ID)
- Expected vs actual behavior
- Environment + build version
- Screenshot / screen recording
- Severity and priority

---

## Example Test Cases

<!-- GUIDANCE: These examples demonstrate the format. Replace with your actual test cases. -->

---

### Test Case: TC-AUTH-001

| Field | Value |
|-------|-------|
| **ID** | TC-AUTH-001 |
| **Title** | User can log in with valid email and password |
| **Description** | Verifies that a registered user can successfully authenticate using correct credentials and is redirected to the dashboard. |
| **Module / Feature** | Authentication — Login |
| **Priority** | Critical |
| **Type** | Functional |
| **Requirement** | REQ-AUTH-001 |
| **Automation Status** | Automated |
| **Automation ID** | `tests/e2e/auth/login.spec.ts:valid-credentials` |

#### Preconditions
1. User account with email `qa-test@example.com` exists and is verified
2. User is not logged in (no active session)
3. Application is accessible at `{{APP_URL}}/login`

#### Test Data
| Field | Value | Notes |
|-------|-------|-------|
| Email | `qa-test@example.com` | Pre-created test account |
| Password | Retrieved from test vault | Never hardcoded |

#### Test Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | Navigate to `{{APP_URL}}/login` | Login page loads with email field, password field, and login button |
| 2 | Enter `qa-test@example.com` in email field | Email value visible in field |
| 3 | Enter valid password in password field | Password masked, not visible |
| 4 | Click "Log In" button | Loading indicator shown, network request initiated |
| 5 | Wait for response | Redirect to `/dashboard` |

#### Expected Final Result
User is authenticated and redirected to `/dashboard`. Auth cookie/token is set. Welcome message visible. Navigation shows user's name/avatar.

#### Post-conditions
- Session exists and is valid
- Audit log entry created for login event
- Test cleanup: session will be cleared in test teardown

---

### Test Case: TC-AUTH-002

| Field | Value |
|-------|-------|
| **ID** | TC-AUTH-002 |
| **Title** | Login fails with invalid password — correct error shown |
| **Description** | Verifies that an incorrect password returns a generic error without revealing whether the email exists (prevents user enumeration). |
| **Module / Feature** | Authentication — Login |
| **Priority** | Critical |
| **Type** | Negative / Security |
| **Requirement** | REQ-AUTH-002, SEC-001 |
| **Automation Status** | Automated |

#### Preconditions
1. User account with email `qa-test@example.com` exists
2. User is not logged in

#### Test Data
| Field | Value |
|-------|-------|
| Email | `qa-test@example.com` |
| Password | `DefinitelyWrongPassword123!` |

#### Test Steps
| Step | Action | Expected Result |
|------|--------|-----------------|
| 1 | Navigate to `/login` | Login form displayed |
| 2 | Enter valid email | Email entered |
| 3 | Enter wrong password | Password masked |
| 4 | Click "Log In" | Form submits |
| 5 | Observe response | Error message displayed: "Invalid email or password" (generic, not "wrong password") |
| 6 | Verify URL | Still on `/login` (no redirect) |
| 7 | Verify no session | No auth cookie set |

#### Expected Final Result
Generic error message shown. User remains on login page. No session created. Error does not reveal whether the email exists.

---

## Related Documents

- [Test Strategy](./test-strategy.md)
- [Test Plan](./test-plan.md)
- [E2E Test Plan](./e2e-test-plan.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Approver | | | |

# Definition of Done

# Definition of Done

> **Project:** {{PROJECT_NAME}}
> **Version:** {{VERSION}}
> **Date:** {{DATE}}
> **Author:** {{AUTHOR}}
> **Status:** Draft | In Review | Approved
> **Reviewers:** {{REVIEWERS}}

## Document History
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1     | {{DATE}} | {{AUTHOR}} | Initial draft |

---

## 1. Purpose

<!-- GUIDANCE: Explain why DoD matters. A shared understanding of "done" prevents quality shortcuts and surprises at release. -->

The Definition of Done (DoD) is a shared agreement across the team on what must be true before any work item can be considered complete. It exists to:

- Prevent technical debt accumulation through rushed or incomplete work
- Ensure consistent quality across all team members and work types
- Create a shared language for "done" that developers, QA, and product all agree on
- Prevent issues from reaching production that could have been caught earlier

**Enforcement:** The DoD is non-negotiable. Exceptions require explicit sign-off from the Tech Lead and must be tracked as technical debt tickets. Undocumented shortcuts are not acceptable.

---

## 2. Feature-Level DoD

<!-- GUIDANCE: This checklist applies to every new feature or significant enhancement. All items must be checked before the work is considered done. -->

When is a **feature** done?

### Code Quality
- [ ] Code is complete and implements all acceptance criteria from the ticket
- [ ] Code reviewed and approved by at least {{REVIEW_COUNT}} reviewer(s)
- [ ] All review comments resolved or explicitly deferred with documentation
- [ ] No TODO/FIXME comments left without corresponding tickets
- [ ] Code follows [coding standards](../DEVELOPER-EXPERIENCE/coding-standards.md) — naming, formatting, patterns
- [ ] No unnecessary dead code added
- [ ] No console.log / debug statements left in production code

### Testing
- [ ] Unit tests written for all new business logic (≥ {{UNIT_COV}}% coverage on new code)
- [ ] Integration tests written for all new service boundaries (API endpoints, DB queries, external calls)
- [ ] E2E tests written for any new critical user journeys
- [ ] All existing tests still pass (no regressions introduced)
- [ ] Test coverage has not decreased below project minimum ({{MIN_COV}}%)
- [ ] Edge cases and error conditions tested

### Accessibility
- [ ] Accessibility verified — all interactive elements keyboard navigable
- [ ] ARIA attributes correct where needed
- [ ] Color contrast meets WCAG AA (4.5:1 for text, 3:1 for large text)
- [ ] Screen reader compatible (tested with {{SCREEN_READER}})
- [ ] No accessibility regressions (automated scan with {{A11Y_TOOL}} passes)

### Security
- [ ] OWASP Top 10 checklist reviewed for this feature
- [ ] Input validation in place for all user inputs
- [ ] Authorization checks correct (user can only access what they're permitted to)
- [ ] No sensitive data logged or exposed in API responses
- [ ] Dependency scan passes (no new HIGH/CRITICAL CVEs introduced)
- [ ] Security code review completed for authentication/authorization changes

### Performance
- [ ] Performance budget met — no P95 regression > {{PERF_REGRESSION}}% vs baseline
- [ ] No N+1 query problems introduced
- [ ] Large datasets paginated or streamed (not loaded into memory)
- [ ] Client-side bundle size impact reviewed (if frontend change)

### Documentation
- [ ] Code is self-documenting or has inline comments for non-obvious logic
- [ ] README updated if developer setup changed
- [ ] Architecture Decision Record created for significant architectural choices
- [ ] User-facing documentation updated (if applicable)

### API (if applicable)
- [ ] API documentation updated (OpenAPI spec / Postman collection)
- [ ] Breaking changes explicitly documented and versioning strategy applied
- [ ] Backwards compatibility maintained or migration guide provided

### Error Handling
- [ ] All error conditions handled gracefully
- [ ] Error messages are user-friendly (no stack traces in production)
- [ ] Errors logged with appropriate severity and context
- [ ] External service failures handled with circuit breakers / fallbacks

### Observability
- [ ] Logging in place for significant events (user actions, errors, integrations)
- [ ] Metrics emitted for new features (request rate, error rate, business events)
- [ ] Alerts configured for new failure modes (if applicable)
- [ ] Traces instrumented for new service calls

### Feature Flags
- [ ] Feature flag configured for the feature (if it's a significant or risky change)
- [ ] Flag documented in feature flag register
- [ ] Rollback plan documented (flag can be disabled to revert)

### Deployment
- [ ] Deployed to staging and manually verified
- [ ] Database migrations tested on staging (up and down)
- [ ] Environment variables documented for any new configuration
- [ ] Product Owner has reviewed and accepted the feature in staging

---

## 3. Sprint-Level DoD

<!-- GUIDANCE: At the end of each sprint, these conditions must be true for the sprint to be considered done. -->

When is a **sprint** done?

- [ ] All committed tickets meet their individual Definition of Done
- [ ] All automated tests passing in CI (unit, integration, E2E)
- [ ] Staging environment is stable (no broken features)
- [ ] Technical debt created during the sprint is tracked in the backlog
- [ ] Sprint review conducted — stakeholders have seen and accepted deliverables
- [ ] Retrospective conducted — process improvements identified and documented
- [ ] Next sprint's tickets are refined and estimated
- [ ] Performance baseline checked — no significant regressions vs last sprint

---

## 4. Release-Level DoD

<!-- GUIDANCE: Before any production release, all these conditions must be true. -->

When is a **release** done?

- [ ] All features in scope meet the Feature-Level DoD
- [ ] Full regression test suite passing on staging
- [ ] E2E tests passing for all critical user journeys
- [ ] Performance test passing — all SLAs met under load
- [ ] Security scan complete — no unresolved HIGH/CRITICAL findings
- [ ] Accessibility audit complete for new/changed UI
- [ ] UAT conducted and sign-off obtained from Product Owner
- [ ] Release notes written and reviewed
- [ ] Deployment checklist complete (see [deployment-checklist.md](../RELEASE/deployment-checklist.md))
- [ ] Rollback plan prepared and tested
- [ ] On-call engineer briefed on changes and potential failure modes
- [ ] Monitoring dashboards updated for new features
- [ ] All critical and high defects resolved or explicitly accepted with justification

---

## 5. Bug Fix DoD

<!-- GUIDANCE: Even bug fixes have quality requirements. -->

When is a **bug fix** done?

- [ ] Root cause understood and documented in the ticket
- [ ] Fix addresses root cause (not just symptoms)
- [ ] Unit/integration test written that would have caught this bug (regression test)
- [ ] Fix does not introduce new failures (all tests passing)
- [ ] Fix verified in the environment where the bug was reported
- [ ] Related areas spot-checked for similar issues
- [ ] Bug ticket updated with root cause and resolution notes

---

## 6. Hotfix DoD

<!-- GUIDANCE: Hotfixes are urgent but still require quality checks. Expedited, not bypassed. -->

When is a **hotfix** done?

- [ ] Fix verified locally and on staging
- [ ] At least 1 reviewer has approved (no solo hotfixes)
- [ ] Smoke tests passing post-deployment
- [ ] Incident ticket updated with the fix details
- [ ] Full regression test run scheduled within {{REGRESSION_SLA}} hours
- [ ] Post-mortem scheduled if P1/P2 severity

---

## 7. Customization Guide

<!-- GUIDANCE: This DoD is a starting point. Adapt it for your project's specific needs. -->

**How to adapt this DoD:**
1. Review each checklist item — mark N/A if genuinely not applicable to your project type
2. Add project-specific items in the appropriate section
3. Adjust thresholds (coverage %, performance budget) to match your NFRs
4. Get explicit agreement from all team members before finalizing
5. Review and update the DoD at each sprint retrospective

**Common adaptations:**
- Mobile apps: Add device testing matrix, app store submission requirements
- Backend-only services: Remove/simplify accessibility and UI performance items
- Highly regulated environments: Add compliance checkboxes (GDPR, HIPAA, etc.)
- Startups / early stage: Simplify coverage requirements while maintaining security basics

---

## Related Documents

- [Test Strategy](./test-strategy.md)
- [Coding Standards](../DEVELOPER-EXPERIENCE/coding-standards.md)
- [Deployment Checklist](../RELEASE/deployment-checklist.md)
- [UAT Sign-off](../RELEASE/uat-signoff.md)

---

## Approval
| Role | Name | Date | Signature |
|------|------|------|-----------|
| Author | | | |
| Reviewer | | | |
| Approver | | | |