Testing

Test strategy, test plan, test cases, E2E, performance, definition of done

Test Strategy: Drop — Fintech Payment App
Test Plan: Drop — Fintech Payment App
Test Case Template: Drop — Fintech Payment App
E2E Test Plan
Performance Test Plan
Definition of Done: Drop — Fintech Payment App
Test Strategy
Test Plan
Test Case Template
Definition of Done

Test Strategy: Drop — Fintech Payment App

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

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

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

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

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

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.

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

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)

Approval

Role	Name	Date	Signature
Author
Reviewer
Approver

Performance Test Plan

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

Approval

Role	Name	Date	Signature
Author
Reviewer
Approver

Definition of Done: Drop — Fintech Payment App

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?

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

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

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)

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

Approval

Role	Name	Date	Signature
Author
Reviewer
Approver

Test Plan

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:

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

Approval

Role	Name	Date	Signature
Author
Reviewer
Approver

Test Case Template

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

Post-conditions

{{POSTCONDITION_1}}
{{POSTCONDITION_2}}

Notes / Edge Cases

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.

Approval

Role	Name	Date	Signature
Author
Reviewer
Approver

Definition of Done

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?

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

Approval

Role	Name	Date	Signature
Author
Reviewer
Approver

Testing

Test Strategy: Drop — Fintech Payment App

Test Strategy: Drop — Fintech Payment App

Document History

1. Testing Philosophy & Principles

2. Test Pyramid

2.1 Unit Tests

2.2 Integration Tests

2.3 E2E Tests

3. Testing Tools

4. Test Environments & Data Management

Test Environments

Test Data Management

5. Test Automation Strategy

6. Manual Testing Scope

7. Code Coverage Requirements

8. Quality Gates

PR Merge Gate (must pass before merge)

Staging Deploy Gate

Production Deploy Gate (must pass before production deploy)

9. Responsibility Matrix

10. Test Reporting & Metrics

11. Continuous Testing in CI/CD

Related Documents

Approval

Test Plan: Drop — Fintech Payment App

Test Plan: Drop — Fintech Payment App

Document History

1. Test Objectives

2. Features Under Test

3. Scope

In Scope

Out of Scope

4. Test Schedule & Milestones

5. Resource Allocation

6. Entry Criteria

7. Exit Criteria

8. Test Strategy Summary Per Type

9. Test Environment Requirements

10. Test Data Requirements

11. Risk-Based Test Prioritization

12. Dependencies & Assumptions

13. Defect Management Process

14. Test Deliverables

Related Documents

Approval

Test Case Template: Drop — Fintech Payment App

Test Case Template: Drop — Fintech Payment App

Document History

1. Test Case ID Format & Naming Convention

2. Test Suite Organization

3. Individual Test Case Format

Test Case: TC-{MODULE}-{SEQ}

Preconditions

Test Data

Test Steps

Expected Final Result

Post-conditions

4. Priority Definitions

5. Test Case Type Definitions

6. Batch Test Execution Template

7. Test Execution Log Format

8. Defect Linking

Example Test Cases — Drop Specific

Test Case: TC-AUTH-001

Preconditions

Test Data

Test Steps

Expected Final Result

Post-conditions

Notes / Edge Cases

Test Case: TC-AUTH-002

Preconditions

Test Data

Test Steps

Expected Final Result

Test Case: TC-DB-001

Preconditions

Test Steps

Expected Final Result