SDLC 04: Quality Assurance Protocols and Test Cases
Revision history: Updated May 2026 — payment testing with MockAdapter; sandbox gateway testing; EC2 test environment; delivery terminology.
1. Testing Levels
| Level | Tool | Scope | Run by |
|---|---|---|---|
| Unit | Jest | Individual functions, utilities, service logic | Local + CI |
| Integration | Jest + Supertest | API route handlers + Prisma DB operations | CI |
| Component | React Testing Library | Frontend components (checkout, overlay, etc.) | CI |
| End-to-End | Playwright | Critical user journeys on staging | Pre-release |
| Payment Sandbox | PawaPay / Flutterwave sandbox | Gateway integration against real sandbox APIs | Manual |
2. Required Test Coverage
| Layer | Minimum coverage |
|---|---|
Backend utilities (utils/) | 90% |
Service layer (services/) | 80% |
Route handlers (routes/) | 100% happy path + key error paths |
Payment service (services/payment/) | 100% (all provider branches, all webhook events) |
| Frontend components | 70% |
3. Payment Testing Strategy
Because real gateway calls must be avoided in CI, the payment system supports three testing modes:
3.1 MockAdapter (Local and CI)
The MockAdapter is used in all automated testing environments to simulate gateway responses (USSD pushes, webhooks, and payment links). This ensures that tests are fast, deterministic, and do not incur costs or call external APIs during integration.
3.2 Sandbox Mode (Manual QA)
For manual QA on the staging environment, the platform is configured in AUTO mode, which routes requests to the real sandbox environments of PawaPay and Flutterwave. This allows for end-to-end verification of the payment orchestration logic against third-party provider systems.
3.3 Integration Testing
The backend includes a comprehensive suite of integration tests that verify API route handlers and database operations. These tests ensure that critical flows, such as payment initiation and order creation, return the correct data structures and handle error states gracefully.
4. Critical E2E Test Cases
The platform tracks several high-value user journeys, including:
- Consumer: Registration, product discovery, mobile money checkout, and card payment redirects.
- Vendor: Shop application, product management, and settlement tracking.
- System: Webhook idempotency, payment timeouts, and fund release orchestration.
5. Test Environment
The platform maintain four distinct environments:
- Local: Developer-specific setup using Docker for local database and cache.
- CI: Automated environment triggered by PRs for linting and testing.
- Staging: Pre-production stack using sandbox gateway integrations.
- Production: The live environment serving real customers and vendors.
6. Continuous Testing
- Automated PR Checks: Linting, unit tests, and integration tests must pass before any merge.
- Security Scanning:
npm auditis integrated into the CI pipeline to block vulnerable dependencies. - Scheduled E2E: Playwright suites run periodically on staging to catch regression issues.
7. Test Data Management
A centralized seeding script provides consistent, synthetic test data across all non-production environments. The test database is automatically reset between integration test runs to ensure state isolation. No production data is ever used in the testing lifecycle.