Test Plan

Test PlanPlan: Drop — Fintech Payment App

Project: {{PROJECT_NAME}}Drop — Remittance + QR Payments Version: {{VERSION}}1.0 Date: {{DATE}}2026-02-23 Author: {{AUTHOR}}John (AI Director) Status: Draft | In Review | Approved Reviewers: {{REVIEWERS}}Alem Bašić (CEO)

Document History

Version	Date	Author	Changes
0.1	{{DATE}}2026-02-23	{{AUTHOR}}John	Initial drafttest plan — all MVP modules

---

1. Test Objectives

This test plan covers testing for {{RELEASE_NAME}}Drop MVP + Phase 0.5 Security Hardening ({{VERSION}}) of {{PROJECT_NAME}}v0.5.0).

Primary objectives:

1. Verify that {{OBJECTIVE_1}}all authentication and onboarding flows (registration, OTP, PIN, login) work correctly for Norwegian residents (age ≥ 18, phone +47)
2. Verify that {{OBJECTIVE_2}}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 nothe regressionpass-through inmodel {{REGRESSION_AREA}}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 productionload load(40+ concurrent users; target 200 for Phase 1)

Out of scope for this plan: SeeBankID Section 3SCA (Scope)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

Builder+

Feature / Story	Priority	Test Types	Owner
{{FEATURE_1}}User Registration — 3-step (FR-001)	Critical	Unit, Integration, E2E	{{OWNER}}Builder + Validator
{{FEATURE_2}}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	{{OWNER}}Builder + Validator
{{FEATURE_3}}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)	{{OWNER}}
Regression — {{AREA}}	High	E2E, Manual	{{OWNER}}Validator

---

3. Scope

In Scope

• {{IN_SCOPE_1}}Authentication module: registration, OTP verification, PIN setup, login, logout, /api/auth/me
• {{IN_SCOPE_2}}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 {{REGRESSION_MODULES}}all 26 API routes
• PerformanceInput testingvalidation: ofXSS, {{PERF_SCOPE}}SQL endpoints
injection,
• Securityboundary testingages, ofUnicode newnames, authenticationlong changespasswords

Out of Scope

testsuite;providerfor

Item	Justification
{{OUT_1}}BankID SCA integration	{{REASON_1}}Phase 2 — not yet implemented
{{OUT_2}}Real BaaS PISP/AISP payments	{{REASON_2}}Phase 2 — mock mode only in MVP
Third-partyReal integrationsSumsub ({{SERVICE}})KYC webhooks	TestedPhase 2 — auto-approved in integrationMVP
Cards responsiblefeature	Phase own3 reliability— 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

Bašić

Milestone	Date	Responsible
Test plan approved	{{DATE}}2026-02-23	QAJohn Lead(AI Director)
Test environment ready (staging)	{{DATE}}Before Phase 0.5 release	PlatformJohn team(DevOps)
Test data seeded	{{DATE}}Before E2E run	QABuilder teamagent
Unit + integration tests complete	{{DATE}}Per PR (CI automated)	DevBuilder teamagent
Playwright E2E test authoring complete	{{DATE}}Before Phase 0.5 release	QABuilder teamagent
Regression testing complete (all 26 routes)	{{DATE}}Before Phase 0.5 release	QAValidator teamagent
Performance benchmarks run	Before Phase 0.5 release	Builder agent
UAT start (CEO walkthrough)	{{DATE}}TBD — before Phase 1 launch	QA + ProductJohn
UAT sign-off	{{DATE}}TBD	ProductAlem Owner
Performance testing complete	{{DATE}}	DevOps + QA(CEO)
Go/no-go decision	{{DATE}}Before Phase 1 launch	EngAlem managerBašić (CEO)
Production release	{{DATE}}Phase 1 (BaaS partner confirmed)	ReleaseJohn manager(AI Director)

---

5. Resource Allocation

AlemBašić

Resource	Role	Testing Activities	Availability
{{PERSON_1}}Builder Agent (Claude Sonnet)	Developer / QA	Unit + integration + E2E authoring	Per task
Validator Agent (Claude Sonnet, read-only)	QA Lead	E2ECode authoring,review regression+ test verification	100%Per task
{{PERSON_2}}John (AI Director)	DeveloperTech Lead	UnitTest +strategy, integrationUAT testscoordination	30% of sprintContinuous
{{PERSON_3}}	Developer	Unit + integration tests	30% of sprint
{{PERSON_4}}	DevOps	Performance, infrastructure	20%
{{PERSON_5}}(CEO)	Product Owner / UAT	CEO UAT review and sign-offwalkthrough	As neededTBD

---

6. Entry Criteria

Testing may begin when:

• Feature development is code-complete (all tickets in "Ready for QA")
• Unit tests passing (≥ {{UNIT_PASS_RATE}}%100% pass rate)
rate
• on Integrationunit tests+ passingintegration suite)
• Build artifact deployed to teststaging environment(https://drop-staging.fly.dev/)
• TestStaging environment is stable (health checks passing)
• Test data is seeded and(npm verified
run
•  Test cases for new features reviewed and approveddb:seed)
• Previous known blocking bugs resolved (seeMission bugControl tracker)backlog reviewed)

---

7. Exit Criteria

Testing is complete when:

• All 14 test casesfiles executedexecute cleanly
• ≥ {{PASS_RATE}}%100% of testunit cases+ integration tests pass
• All Critical and High defectstest resolved or accepted with justification
•  Medium defects reviewed — plancases in placeAC-001–AC-092 for outstanding itemspass
• Code coverage ≥ {{COVERAGE_GATE}}%80% overall; 100% for auth + transaction paths
•  All Playwright E2E tests passing on staging (user-flows, full-flows, input-chaos)
• Performance testsbenchmarks meeting SLANFR-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 ProductAlem OwnerBašić (CEO) — or conditional approval documented
• Go/no-goSecurity checklistaudit completescore ≥ 80/100 (seepost SectionPhase 14)
0.5
•  Release notes updated with test summaryhardening)

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

---

8. Test Strategy Summary Per Type

Phase1

Type	Approach	Tool	Owner	Gate
Unit	White-box,box TDD— wherebcrypt, applicableJWT, fee calc, validators	{{UNIT_TOOL}}Vitest	DevelopersBuilder	Blocks merge
Integration	Real dependenciesSQLite viatest TestContainersDB — 26 API routes, DB schema	{{INT_TOOL}}Vitest	DevelopersBuilder	Blocks merge
E2E	Critical userjourneys journeys,on automatedstaging — 3 Playwright projects	{{E2E_TOOL}}Playwright	QABuilder	Blocks release
Regression	AutomatedAll suite26 +routes targetedvia manualapi-endpoints.test.ts	{{E2E_TOOL}} + manualVitest	QABuilder	Blocks releasemerge
Performance	Loadapi-benchmarks.test.ts test— atbcrypt {{LOAD_PROFILE}}timing, query latency	{{PERF_TOOL}}Vitest bench	DevOpsBuilder	BlocksWarning → release
Security	SASTnpm audit + SCAvalidation.test.ts + manual reviewmiddleware.test.ts	{{SAST_TOOL}}Vitest + GitHub Actions	DevOpsBuilder	Blocks merge
DB compliance	db.test.ts — schema assertions	Vitest	Builder	Blocks merge
UAT	BusinessCEO business scenario validationwalkthrough	Manual	ProductAlem OwnerBašić	Blocks release
Accessibility	Automated + manual audit	{{A11Y_TOOL}}	Developer + QA	Warninglaunch

---

9. Test Environment Requirements

Environment	Purpose	URL	Access Needed
DevLocal dev	Unit/integration	dev.{{DOMAIN}}http://localhost:3000	AllBuilder team membersagent
Staging (Fly.io, Stockholm)	E2E, regression, UAT	https://drop-staging.{{DOMAIN}}fly.dev/	Team + PM + stakeholdersAlem
Performance	Load testingBenchmarks	IsolatedLocal (production-sized)api-benchmarks.test.ts)	DevOpsBuilder + QAagent

Environment requirements:

• Staging must have production-equivalentNEXT_PUBLIC_SERVICE_MODE=mock configuration(no real BaaS)
• TestStaging databaseSQLite DB seeded with {{DATA_VOLUME}}synthetic records
• Third-party integrations in sandbox/test modedata (no real PII)
• Monitoring enabled (sameFly.io as production)metrics)

---

10. Test Data Requirements

Data Category	Volume	Creation Method	Responsible
Test userconsumer accounts	{{USER_COUNT}}3 (fresh, KYC-approved, KYC-pending)	scripts/seed-users.shnpm run db:seed	QABuilder teamagent
{{DATA_TYPE_1}}Test merchant accounts	{{VOLUME}}2 (registered, unregistered)	Factorynpm /run fixturesdb:seed	QABuilder teamagent
{{DATA_TYPE_2}}Test recipients (for remittance)	{{VOLUME}}3	Anonymizednpm fromrun productiondb:seed	DevOpsBuilder agent
Edge case data (emptyunder-18, states,duplicate email, max values)amounts)	Defined per test	Manual /Vitest fixtures	QABuilder teamagent

Data cleanup: All test data removed after test run via Vitest scripts/cleanup.shafterEach teardown. Staging DB reset between major test runs.

---

11. Risk-Based Test Prioritization

balance suite

Risk Area	Likelihood	Impact	Priority	Mitigation
PaymentPass-through processingmodel failureviolation (Drop stores balance)	MediumLow	Critical	P1	Fulldb.test.ts regressionalways +asserts manualno 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 codecolumn
Authentication edge casesbypass	Low	Critical	P1	Full authauth.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:

• PlatformStaging teamenvironment provisionsprovisioned and accessible at https://drop-staging.fly.dev/
• Mock BaaS and Mock Sumsub configured in staging environment by {{DATE}}variables
• {{THIRD_PARTY}}Playwright sandboxinstalled environmentin available
CI
• Security(npx teamplaywright approves SAST configuration by {{DATE}}install)

Assumptions:

• Feature requirements will not change during the testing phase without John (AI Director) review
• All developersBuilder willagent respondPRs toinclude bugstests withinalongside {{BUG_RESPONSE_SLA}} hourscode
• UATValidator participantsagent arereviews availabletest perfiles thebefore schedulemerge
in
• BaaS Sectionpartnership 4not confirmed — mock mode accepted for MVP/staging

---

13. Defect Management Process

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

Severity	Definition	Resolution SLA
Critical	SystemFinancial unusable,invariant broken; auth bypass; data loss, security issueloss	Fix before release — no exceptions
High	Major feature broken,broken; security finding; no workaround	Fix before release
Medium	Feature degraded,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: DailyOn duringeach PR/commit (CI-driven); daily for active testingtest phase

---

14. Test Deliverables

Deliverable	Format	Due Date	Owner
Test plan (this document)	Markdown	{{DATE}}2026-02-23	QAJohn Lead(AI Director)
Test strategy	test-strategy.md	2026-02-23	John
Test cases (automated)	{{BUG_TRACKER}}Vitest /+ MarkdownPlaywright test files	{{DATE}}Per sprint	QABuilder teamagent
Test execution results	AutomatedVitest + Playwright CI reports + summary	{{DATE}}Per PR	QA team
Defect report	{{BUG_TRACKER}}	Ongoing	QA teamCI
Performance test report	Markdownapi-benchmarks.test.ts + chartsoutput	{{DATE}}Per release	DevOpsBuilder agent
UAT sign-off	Signed uat-signoff.md	{{DATE}}Before Phase 1	ProductAlem OwnerBašić
Test summary report	Markdown (per release)	{{DATE}}Per release	QAValidator Leadagent

---

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)
ReviewerQA Lead	Validator Agent	2026-02-23	Approved (AI)
ApproverAI Director (John)	John	2026-02-23	Approved
CEO (Alem)	Alem Bašić	TBD