Test Plan: Drop — Fintech Payment App

Performance 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

1. Performance TestingTest Objectives

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

Primary objectives:

1. Verify that all authentication and onboarding flows (registration, OTP, PIN, login) work correctly for Norwegian residents (age ≥ 18, phone +47)
2. Verify that remittance transactions apply correct 0.5% fee across all 6 NOK corridors with mock BaaS
3. Verify that QR payments apply correct 1% merchant fee with mock BaaS
4. Confirm the pass-through model invariant: Drop NEVER stores user balances or full card data
5. Confirm Phase 0.5 security hardening: bcrypt 12 rounds, persistent rate limiting, CSRF, security headers, audit logging
6. Validate that Drop meets the performance SLAs defined in the NFR document under normalexpected operating conditionsload (20040+ concurrent usersusers; ontarget SQLite200 MVP; 5,000+ on PostgreSQLfor Phase 1)
7. Determine the SQLite concurrent user limit before migrating to PostgreSQL (target: migrate at 200 concurrent)
8. Identify bottlenecks (bcrypt hashing, DB queries, rate limiter) before production release
9. Establish a performance baseline for regression comparison in future releases

ReferenceOut NFRs:of scope for this plan: docs/BUSINESS-REQUIREMENTS/non-functional-requirements.mdBankID — Section 2SCA (Performance)Phase 2), real BaaS payments (Phase 2), real Sumsub KYC (Phase 2), Cards feature (Phase 3), mobile native app (Phase 2).

2. PerformanceFeatures RequirementsUnder ReferenceTest

3. Test TypesScope

3.1In Load Testing — Normal Load SimulationScope

Objective:

Confirm
• Authentication Dropmodule: meetsregistration, SLAsOTP underverification, expectedPIN normalsetup, loadlogin, 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 (Norwegianno remittancebalance, corridorno peakcard_number, traffic)no Normalcvv), loadFK definition:constraints, 200transaction type enum
• Performance benchmarks: bcrypt timing, DB query latency, concurrent users (SQLite MVP limit) / ~20 requests/second Duration: 10 minutes (after 2-minute ramp-up) Pass criteria: All SLA targets in Section 2 met with ≤ 0.1% error rate

  3.2 Stress Testing — Beyond Normal Capacity

  Objective: Find SQLite concurrent user limit; understand failure behavior to plan PostgreSQL migration Starting point: 50 users, increasing by 25 users every 2 minutes Stop condition: Error rate >limit 5%check orthroughput

P99
• Regression > 3,000ms or service crashes Pass criteria: System fails gracefully with meaningful error messages (429 rate limit, not 500); data integrity maintained; no double-spend under stress

  3.3 Spike Testing — Sudden Traffic Surges

  Objective: Simulate scenarios like marketing campaigns or media coverage causing sudden user influx Baseline: 20 users Spike to: 100 users (5× baseline) Spike duration: 2 minutes Pass criteria: System recovers to baseline performance within 5 minutes after spike ends; no data corruption

  3.4 Endurance / Soak Testing — Sustained Load

  Objective: Identify SQLite file lock issues, connection pool exhaustion, memory leaks under sustained load Load level: 50 users (25%testing of 200all concurrent26 limit)API Duration:routes

2
• Input hoursvalidation: MetricsXSS, toSQL watch:injection, SQLiteboundary writeages, queueUnicode depth,names, memorylong usagepasswords
trend, response time trend Pass criteria: No upward trend in response time over soak period; no SQLite database locked errors

3.5Out Scalabilityof Testing — Phase 1 PostgreSQL MigrationScope

Objective: Verify PostgreSQL migration enables proportional scaling for Phase 1 target (5,000+ users) Test: Step load from 200 to 1,000 concurrent users on PostgreSQL staging Pass criteria: P95 stays under 500ms as concurrent users scale; no P99 explosion Note: PostgreSQL not yet deployed — Phase 1 task. This plan establishes the baseline for comparison.

4. Load Profiles

Think time simulation: Realistic user think time of 2–5s (Norwegian users reviewing remittance details before confirming)

5.4. Test EnvironmentSchedule & Milestones

NOTE: Performance tests run against a representative staging environment. SQLite MVP limits are tested on Fly.io staging (1× shared CPU, 256MB RAM). Phase 1 PostgreSQL tests require production-equivalent environment.

5. Resource Allocation

6. Entry Criteria

Testing may begin when:

•  Feature development is code-complete (landing)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

9. Test Environment Requirements

LoadEnvironment generator:requirements:

• Tool:Staging Vitestmust benchmarkshave NEXT_PUBLIC_SERVICE_MODE=mock (api-benchmarks.test.ts)no forreal micro-benchmarksBaaS)
• LoadStaging generatorSQLite forDB integration:seeded k6with scriptssynthetic intest infrastructure/performance/data (no real PII)
• LoadMonitoring generator location: Local or CI runnerenabled (same region as Fly.io Stockholm)metrics)

6.10. Test Data Requirements

DatabaseData sizecleanup: atAll test time:data ~50MBremoved SQLiteafter file Data preparation: npmtest run db:seed:perfvia Vitest afterEach (estimatedteardown. time:Staging ~2DB minutes)reset between major test runs.

Drop-specific bottleneck investigation order:

1. Check bcrypt timing → bcrypt > 1,000ms P95 = config issue (rounds too high OR long password pre-check missing)
2. Check SQLite write queue → "database is locked" errors = concurrent write saturation → trigger PostgreSQL migration
3. Check rate limiter DB table → rate_limit_requests table query slow = add index or migrate to Redis
4. Check transaction lock → SELECT FOR UPDATE timeout = deadlock in double-spend prevention
5. Check mock BaaS response → mock service timeout = CI/staging environment issue
6. Check Fly.io metrics → CPU > 90% = scale up instance; Memory > 200MB = Node.js leak check