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

1. Test Objectives

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

Primary objectives:

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

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

2. Features Under Test

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

4. Test Schedule & Milestones

5. Resource Allocation

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

9. Test Environment Requirements

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 cleanup: All test data removed after test run via Vitest afterEach teardown. Staging DB reset between major test runs.

11. Risk-Based Test Prioritization

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:

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

Related Documents

• Test Strategy
• Test Case Template
• E2E Test Plan
• Performance Test Plan
• Definition of Done
• UAT Sign-off
• Testing Guide
• Test Inventory

Approval