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: 
 
 Tests are first-class code — reviewed, maintained, refactored like production code 
 Test the behavior, not the implementation — tests enable safe refactoring 
 Fast feedback — unit/integration tests run in seconds; blocking tests run in < 3 minutes 
 Tests document intent — a failing test explains what broke and why it matters 
 Shift left — find bugs as early as possible, before they reach users 
 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 
 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: 
 
 User registration (3 steps: email+DOB → OTP → PIN) 
 User login + dashboard access 
 Remittance (NOK → RSD/BAM/PKR/TRY/PLN/EUR) 
 QR payment (scan → confirm → receipt) 
 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 
 E2E Test Plan 
 Performance Test Plan 
 Definition of Done 
 Testing Guide 
 Test Inventory 
 
 
 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: 
 
 Verify that all authentication and onboarding flows (registration, OTP, PIN, login) work correctly for Norwegian residents (age ≥ 18, phone +47) 
 Verify that remittance transactions apply correct 0.5% fee across all 6 NOK corridors with mock BaaS 
 Verify that QR payments apply correct 1% merchant fee with mock BaaS 
 Confirm the pass-through model invariant: Drop NEVER stores user balances or full card data 
 Confirm Phase 0.5 security hardening: bcrypt 12 rounds, persistent rate limiting, CSRF, security headers, audit logging 
 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 
 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 
 Before Phase 1 
 Alem Bašić 
 
 
 Test summary report 
 Markdown (per release) 
 Per release 
 Validator agent 
 
 
 
 
 Related Documents 
 
 Test Strategy 
 Test Case Template 
 E2E Test Plan 
 Performance Test Plan 
 Definition of Done 
 UAT Sign-off 
 Testing Guide 
 Test Inventory 
 
 
 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 
 
 {PRECONDITION_1} 
 {PRECONDITION_2} 
 {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 
 
 Fresh email address not previously registered in Drop 
 Norwegian phone number (+47) 
 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 
 
 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 
 
 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 Plan 
 E2E Test Plan 
 Acceptance Criteria 
 
 
 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 

 Objectives: 
 
 Validate that the {{COUNT}} most critical user journeys work end-to-end in a production-like environment 
 Catch integration failures between frontend, backend, and third-party services that unit/integration tests cannot detect 
 Provide confidence before every production deployment 
 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 

 Journey 1: {{JOURNEY_1_NAME}} 
 
 
 
 Field 
 Value 
 
 
 
 
 Priority 
 Critical 
 
 
 Business Impact 
 {{IMPACT}} 
 
 
 Frequency 
 {{FREQUENCY}} 
 
 
 Test File 
 {{TEST_PATH}} 
 
 
 
 Steps: 
 
 {{STEP_1}} 
 {{STEP_2}} 
 {{STEP_3}} 
 {{STEP_4}} 
 {{STEP_5}} 
 {{STEP_6}} 
 
 Assertions: 
 
 {{ASSERTION_1}} 
 {{ASSERTION_2}} 
 {{ASSERTION_3}} 
 
 
 Journey 2: {{JOURNEY_2_NAME}} 
 
 
 
 Field 
 Value 
 
 
 
 
 Priority 
 Critical 
 
 
 Business Impact 
 {{IMPACT}} 
 
 
 Frequency 
 {{FREQUENCY}} 
 
 
 Test File 
 {{TEST_PATH}} 
 
 
 
 Steps: 
 
 {{STEP_1}} 
 {{STEP_2}} 
 {{STEP_3}} 
 

 
 All Journeys Summary 

 
 
 
 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 

 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 

 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 

 
 
 
 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 

 Strategy: {{AUTH_STRATEGY}} 
 Recommended approach (Playwright): 
 // 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 

 
 
 
 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 

 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 

 Tool: {{VIS_TOOL}} 
 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 

 
 
 
 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 

 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: 
 # 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 

 Report format: {{REPORT_FORMAT}} 
 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 

 Page Object Pattern: 
 
 All page interactions wrapped in Page Object classes 
 Selectors centralized — change in one place 
 Location: tests/e2e/pages/ 
 
 Selector strategy: 
 
 data-testid attributes (preferred — stable, intent-clear) 
 ARIA roles + accessible name (good for accessibility alignment) 
 Text content (acceptable for static text) 
 CSS class names (avoid — coupled to styling) 
 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 Plan 
 Test Case Template 
 CI/CD Pipeline 
 
 
 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 

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

 
 
 
 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 
 
 
 
 
 
 

 
 3. Test Types 
 3.1 Load Testing — Normal Load Simulation 

 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 

 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 

 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 

 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 

 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 

 
 
 
 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 

 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}} 
 Load generator location: {{LG_LOCATION}} (same region as app, separate VPC) 
 Load generator sizing: {{LG_SPEC}} 
 
 
 6. Test Data Requirements 

 
 
 
 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 

 
 
 
 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 

 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 

 
 
 
 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 

 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 

 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 

 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 

 
 
 
 Issue 
 Found In 
 Severity 
 Root Cause 
 Fix 
 Fixed In 
 Verified 
 
 
 
 
 {{ISSUE}} 
 {{SCENARIO}} 
 {{SEVERITY}} 
 {{CAUSE}} 
 {{FIX}} 
 {{VERSION}} 
 {{DATE}} 
 
 
 
 
 Related Documents 
 
 Test Strategy 
 Monitoring & Observability 
 SLA Report 
 
 
 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: 
 // 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: 
 
 Unit test in transactions.test.ts verifying exact fee amount 
 Boundary test at minimum amount (100 NOK) and maximum amount (50,000 NOK) 
 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 
 Coding Standards 
 Deployment Checklist 
 UAT Sign-off 
 Acceptance Criteria 
 
 
 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 

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

 
 2. Test Pyramid 

 pyramid
 title Test Distribution
 accTitle: Test Distribution by Layer
 "Unit Tests (70%)" : 70
 "Integration Tests (20%)" : 20
 "E2E Tests (10%)" : 10
 
 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 

 
 
 
 Attribute 
 Value 
 
 
 
 
 Scope 
 Individual functions, classes, pure business logic 
 
 
 External dependencies 
 Mocked (no real DB, network, or filesystem calls) 
 
 
 Framework 
 {{UNIT_FRAMEWORK}} 
 
 
 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}} 
 
 
 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: 
 
 {{JOURNEY_1}} 
 {{JOURNEY_2}} 
 {{JOURNEY_3}} 
 

 
 3. Testing Tools 

 
 
 
 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 

 
 
 
 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 

 
 
 
 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 

 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 

 
 
 
 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 

 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 

 
 
 
 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 

 
 
 
 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 

 See CI/CD Pipeline 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 
 E2E Test Plan 
 Performance Test Plan 
 Definition of Done 
 CI/CD Pipeline 
 
 
 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 

 This test plan covers testing for {{RELEASE_NAME}} ({{VERSION}}) of {{PROJECT_NAME}}. 
 Primary objectives: 
 
 Verify that {{OBJECTIVE_1}} 
 Verify that {{OBJECTIVE_2}} 
 Confirm no regression in {{REGRESSION_AREA}} 
 Validate performance under expected production load 
 
 Out of scope for this plan: See Section 3 (Scope). 
 
 2. Features Under Test 

 
 
 
 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}} 
 
 
 

 
 3. Scope 
 In Scope 

 
 {{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 

 
 
 
 Item 
 Justification 
 
 
 
 
 {{OUT_1}} 
 {{REASON_1}} 
 
 
 {{OUT_2}} 
 {{REASON_2}} 
 
 
 Third-party integrations ({{SERVICE}}) 
 Tested in integration test suite; provider responsible for own reliability 
 
 
 
 
 4. Test Schedule & Milestones 

 
 
 
 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 

 
 
 
 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 

 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 

 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 

 
 
 
 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 

 
 
 
 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 

 
 
 
 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 

 
 
 
 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 

 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 

 Bug tracker: {{BUG_TRACKER}} 
 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 

 
 
 
 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 
 {{DATE}} 
 Product Owner 
 
 
 Test summary report 
 Markdown 
 {{DATE}} 
 QA Lead 
 
 
 
 
 Related Documents 
 
 Test Strategy 
 Test Case Template 
 E2E Test Plan 
 Performance Test Plan 
 Definition of Done 
 UAT Sign-off 
 
 
 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 

 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 

 
 
 
 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}} 
 
 
 

 
 3. Individual Test Case Format 

 
 Test Case: TC-{{MODULE}}-{{SEQ}} 
 
 
 
 Field 
 Value 
 
 
 
 
 ID 
 TC-{{MODULE}}-{{SEQ}} 
 
 
 Title 
 {{CONCISE_DESCRIPTION}} 
 
 
 Description 
 {{FULL_DESCRIPTION}} 
 
 
 Module / Feature 
 {{MODULE_NAME}} 
 
 
 Priority 
 {{PRIORITY}} 
 
 
 Type 
 {{TYPE}} 
 
 
 Requirement 
 {{REQ_ID}} / {{STORY_ID}} 
 
 
 Automation Status 
 {{STATUS}} 
 
 
 Automation ID 
 {{AUTOMATION_ID}} 
 
 
 
 Preconditions 

 
 {{PRECONDITION_1}} 
 {{PRECONDITION_2}} 
 {{PRECONDITION_3}} 
 
 Test Data 

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

 
 
 
 Step 
 Action 
 Expected Result 
 
 
 
 
 1 
 {{ACTION_1}} 
 {{EXPECTED_1}} 
 
 
 2 
 {{ACTION_2}} 
 {{EXPECTED_2}} 
 
 
 3 
 {{ACTION_3}} 
 {{EXPECTED_3}} 
 
 
 4 
 {{ACTION_4}} 
 {{EXPECTED_4}} 
 
 
 
 Expected Final Result 

 {{OVERALL_EXPECTED_RESULT}} 

 Post-conditions 

 
 {{POSTCONDITION_1}} 
 {{POSTCONDITION_2}} 
 
 Notes / Edge Cases 

 
 {{NOTE_1}} 
 Related: TC-{{RELATED_ID}} 
 
 
 4. Priority Definitions 

 
 
 
 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 

 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 

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

 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 

 
 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 
 
 User account with email qa-test@example.com exists and is verified 
 User is not logged in (no active session) 
 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 
 
 User account with email qa-test@example.com exists 
 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 Plan 
 E2E Test Plan 
 
 
 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 

 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 

 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 — 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 

 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 

 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 ) 
 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 

 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 

 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 

 How to adapt this DoD: 
 
 Review each checklist item — mark N/A if genuinely not applicable to your project type 
 Add project-specific items in the appropriate section 
 Adjust thresholds (coverage %, performance budget) to match your NFRs 
 Get explicit agreement from all team members before finalizing 
 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 
 Coding Standards 
 Deployment Checklist 
 UAT Sign-off 
 
 
 Approval 
 
 
 
 Role 
 Name 
 Date 
 Signature 
 
 
 
 
 Author 
 
 
 
 
 
 Reviewer 
 
 
 
 
 
 Approver