Home ▸ Phases (0-13) ▸ Phase 10: Testing & Quality

PHASE 10: Testing & Quality

Trigger: "Execute Phase 10 as per masterplan."

Goal: Comprehensive test coverage (80%+), security audit with 0 P0/P1 findings, E2E tests mapped to Chapter 08 user journeys, and performance baseline with k6 scripts.

Prerequisite: Phase 9 is completed.

Step 10.0 — Technical Conception

Create doc/developer/conception/phase-10-conception.md.

(reference: Chapter 08 — User Journeys, Chapter 13 — Security, Chapter 14 — Infrastructure)

Content: - Scope: Test gap analysis, test generation, E2E user journey tests, security audit, performance baseline - Test Pyramid: Unit (70%) / Integration (20%) / E2E (10%) distribution - E2E Scenarios: Map to Chapter 08 user journeys (5 critical paths) - Performance Targets: From Chapter 09 (FCP < 0.2s), Chapter 14 (p95 API < 500ms) - Security Checklist: OWASP Top 10 mapped to all modules - Design Chapter References: Ch08, Ch09, Ch13, Ch14

Result: Technical conception for Phase 10.

Step 10.1 — Test Strategy

Create doc/testing/test-strategy.md.

(reference: Chapter 14 — Infrastructure)

  1. Testing pyramid: unit (70%), integration (20%), E2E (10%)
  2. Coverage target: 80% line coverage
  3. Test data strategy: factories, fixtures, Testcontainers
  4. Environment: Testcontainers (PostgreSQL, Redis), WireMock (Cash360)

Result: Test strategy document.

Step 10.2 — Unit and Integration Tests

Approach:

  1. Coverage Audit: - Run JaCoCo with ./mvnw verify, generate module-level report - Identify modules below 80% threshold, list uncovered critical paths - Prioritize by risk: payment > auth > contract > billing > member > others

  2. Unit Tests (per module, target: every service method): - membership-auth: Login success/failure, token refresh, brute-force lockout (5 attempts), password reset flow, email verification token expiry - membership-member: CRUD, search, custom attributes (JSONB edge cases), member number generation uniqueness, emergency contacts, minor member (age validation) - membership-contract: Purchase (age check, capacity), sign, cancel within/past notice period, auto-renewal, expire, suspend/resume, state machine transitions (invalid transitions rejected) - membership-payment: Billing cycle (due contracts, batch creation, Cash360 submission), storno full/partial, balance calculation, webhook processing (valid/invalid HMAC, status transitions, replay rejection) - membership-product: CRUD, catalog filtering, stock management, VAT calculation (gross/net) - membership-checkin: QR validation, access zone check, anti-passback, credential fallback chain - membership-communication: Template variable substitution, locale fallback, email rendering, bulk rate limiting - membership-crm: Pipeline stage transitions, lead-to-member conversion, activity logging - membership-support: SLA deadline calculation (business hours, timezone), ticket lifecycle, CSAT score - membership-accounting: Double-entry validation (debit = credit), DATEV CSV format, period close lock, reconciliation

  3. Integration Tests: - Controller tests (MockMvc): All endpoints — request validation, auth enforcement (401/403), pagination, error responses - Cash360 client (WireMock): All 11 endpoints, error responses (400, 404, 500), circuit breaker tripping (5 consecutive 500s), retry behavior - Database (Testcontainers + PostgreSQL): Repository custom queries, Flyway migrations run cleanly, tenant isolation (entity A can't read entity B data), optimistic locking (@Version conflict) - RabbitMQ (Testcontainers): Billing event → accounting entry, notification triggers, import job processing

  4. Test Data Factories: - MemberFactory, ContractFactory, TransactionFactory, OrganizationFactory - Builder pattern with sensible defaults, overridable fields

Validation:

cd backend && ./mvnw verify
# JaCoCo >= 80% line coverage (enforced by maven-enforcer-plugin)

Result: 80%+ test coverage with comprehensive unit and integration tests across all 16 modules.

Step 10.3 — E2E Tests (User Journey-Based)

Map E2E tests to Chapter 08 user journeys.

(reference: Chapter 08 — User Journeys)

Approach:

  1. Set up Playwright for Flutter Web testing
  2. 5 critical user journey tests:
# Journey (from Ch08) Test Scenario
1 Journey 1: Member Registration Register -> verify email -> login -> browse memberships -> purchase -> sign contract -> view QR code
2 Journey 2: Admin Member Mgmt Login as admin -> create member -> assign membership -> run billing -> verify transaction in Cash360 -> view report
3 Journey 3: Trainer Course Login as trainer -> view today's courses -> open participant list -> mark attendance -> add session note
4 Journey 6: DATEV Monthly Close Login as accountant -> review month's entries -> run reconciliation -> export DATEV CSV -> close period
5 Journey 8: Support Ticket Login as member -> create ticket -> receive assignment notification -> agent responds -> member confirms resolution -> CSAT survey

Detailed E2E test steps (Journey 1 — Member Registration): 1. Navigate to /p/{entity-slug} (public homepage) 2. Click "Jetzt Mitglied werden" button 3. Fill registration form: email, password, first name, last name 4. Submit -> verify "Verification email sent" message displayed 5. Open email (MailHog/Mailtrap), click verification link 6. Verify redirect to login page with "Email verified" message 7. Login with registered credentials 8. Verify redirect to member dashboard 9. Navigate to membership catalog 10. Select "Premium Membership" -> click "Purchase" 11. Verify contract details displayed (price, term, auto-renewal) 12. Click "Sign contract" (digital signature) 13. Verify contract status = ACTIVE in member profile 14. Navigate to "My QR Code" -> verify QR code displayed 15. Verify QR code contains valid check-in token

  1. Run against staging environment with Testcontainers backend (PostgreSQL, Redis, RabbitMQ, WireMock for Cash360)
  2. Tests produce screenshots on failure for debugging
  3. Test data setup: Each E2E test creates its own organization + admin user via API (isolation)
  4. Parallelization: Each journey test runs independently (no shared state), can run in parallel

Result: Automated E2E tests for 5 critical user journeys.

Step 10.4 — Security Audit

(reference: Chapter 13 — Security and Compliance)

Approach (OWASP Top 10 + GDPR):

  1. A01 Broken Access Control: - Verify tenant isolation: member of Entity A cannot access Entity B's data (test all endpoints with cross-entity IDs) - Verify role enforcement: MEMBER cannot access admin endpoints, TRAINER limited to own courses - Verify object-level access: member can only see own transactions, contracts, bank accounts - Test horizontal privilege escalation: change memberId in request body

  2. A02 Cryptographic Failures: - JWT RS256 with 2048-bit+ RSA key pair (no HS256, no hardcoded secret) - Passwords: bcrypt cost factor 12 (verify with test) - IBAN stored in plain text (acceptable, not a secret) but masked in API responses - API keys stored encrypted (sealed-secrets in K8s, not in application.yml)

  3. A03 Injection: - SQL injection: verify all queries use parameterized statements (JPA/Hibernate default) - XSS: verify all API responses use Content-Type application/json, HTML template outputs escaped - JSONB injection: verify custom attributes are sanitized before storage - File upload: verify MIME type whitelist, filename sanitization, path traversal prevention

  4. A04 Insecure Design: - Billing engine: verify idempotency (no double billing) - Storno: verify cannot storno already-storno'd transaction - Contract: verify state machine (invalid transitions rejected) - Webhook: verify HMAC validation (reject forged webhooks)

  5. A05 Security Misconfiguration: - CORS: explicit origin whitelist (no wildcard *) - HSTS: Strict-Transport-Security header in production - CSP: Content-Security-Policy header for admin web - Stack traces: not exposed in production error responses - Actuator: health endpoint public, all others require SYSTEM_ADMIN

  6. A07 Authentication: - Brute-force: verify lockout after 5 failed attempts (Redis counter, 15min lockout) - Token expiry: access token 15min, refresh token 30 days, expired tokens rejected - Password policy enforcement: min 8 chars, uppercase, number, special char (configurable)

  7. Dependency Audit: - Trivy container image scan (0 CRITICAL, 0 HIGH) - OWASP dependency-check Maven plugin (no known CVEs in dependencies) - License compliance check (all permissive, per Ch13 inventory)

  8. GDPR Compliance: - Art. 13/14: Privacy policy accessible, data processing purposes documented - Art. 15: Member can view all stored personal data - Art. 17: Deletion request → 30-day grace period → anonymization (not hard delete, preserve audit trail) - Art. 20: Data portability export (JSON, all personal data, transactions, contracts) - Art. 25: Privacy by design (minimal data collection, tenant isolation, encrypted storage) - Art. 28: AVV/DPA template auto-generated per customer - Art. 30: Processing activities register (documented) - No PII in application logs (verify: email, name, IBAN, phone not logged at INFO/WARN/ERROR)

  9. Write report: doc/testing/security-audit.md — findings per OWASP category, severity, remediation status

Result: Security audit report with 0 P0/P1 findings. All OWASP Top 10 and GDPR requirements verified.

Step 10.5 — Performance Testing

(reference: Chapter 09 (FCP < 0.2s), Chapter 14)

Approach:

  1. k6 load test scripts in backend/src/test/k6/: - login-flow.js — 100 concurrent logins, measure token generation time - member-search.js — 100 concurrent searches with filters, paginated - billing-cycle.js — Trigger billing for 1,000 contracts, measure throughput - checkin-burst.js — 50 concurrent check-ins (simulates morning rush) - api-crud.js — Mixed CRUD operations across all modules
  2. Baseline metrics (all measured per endpoint group):
Metric Description Tool
API p50/p95/p99 Response time percentiles k6 http_req_duration
DB p95 Database query time Micrometer db.query.duration
Throughput Requests/second sustained k6 http_reqs
Error rate 4xx + 5xx / total requests k6 http_req_failed
Memory JVM heap usage under load Micrometer jvm.memory.used
CPU Application CPU % Micrometer process.cpu.usage
Connection pool Active/idle DB connections HikariCP metrics
  1. Performance targets:
Endpoint Group p95 Target Throughput Target Notes
Auth (login, refresh) < 200ms 50 rps bcrypt is CPU-bound
Member CRUD < 300ms 100 rps Includes JSONB serialization
Member search < 500ms 50 rps Full-text search with filters
Billing cycle < 100ms/contract 1,000 contracts/60s Batch processing
Check-in < 200ms 30 rps Morning rush scenario
Reports/Dashboard < 1000ms 10 rps Aggregation queries, cacheable
Cash360 API calls < 2000ms 10 rps Depends on external API
PDF generation < 3000ms 5 rps CPU-bound, async via RabbitMQ
  1. Staging data: Generate via PerformanceDataSeeder: - 50 organizations (mix of Starter/Team/Professional) - 10,000 members (200 per organization average) - 5,000 contracts - 50,000 transactions (10 months of billing history) - 2,000 courses with 100,000 attendance records - 500 support tickets
  2. Write report: doc/testing/performance-report.md with charts and recommendations

Result: Performance baseline established. Bottlenecks identified and resolved.

Step 10.6 — Phase 10 Documentation

  1. Create doc/enduser/faq.md (members, admins, trainers, troubleshooting)
  2. Review and finalize all existing documentation
  3. Create doc/testing/coverage-report.md (JaCoCo summary)

Step 10.7 — Update Intranet

Run python doc/intranet/build.py.

Phase 10 — Quality Gate

# Check Target
1 Conception exists
2 JaCoCo coverage >= 80%
3 E2E tests 5 user journey tests pass
4 Security audit 0 P0/P1 findings
5 Performance p95 < 500ms API, < 100ms DB
6 k6 scripts 5 scripts in repository
7 FAQ exists
8 All test reports in doc/testing/
9 Documentation + intranet updated
10 CLAUDE.md updated

Report: "Phase 10 completed." with coverage %, test count, security finding count, p95 latency.

---