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

1. Testing Philosophy & Principles

Core Principles:

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

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

2. Test Pyramid

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

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

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

Critical journeys covered by E2E:

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

3. Testing Tools

4. Test Environments & Data Management

Test Environments

Test Data Management

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

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

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

10. Test Reporting & Metrics

11. Continuous Testing in CI/CD

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