System test plan

Manual, human-executed end-to-end tests of both apps against a real backend. They complement the unit tests (see Testing & validation) and act as the release gate: a release candidate ships only after a recorded test run.

Test cases trace to the requirements catalogs: every case declares which requirement IDs it covers, and each protocol ends with a coverage table.

Protocols

Protocol	App	Cases
Tracking app system tests	@enode/tracking	TRK-ST-*
Portal system tests	@enode/portal	POR-ST-*
Planner manual test protocol	portal Planner deep-dive	referenced from the portal protocol §Planner

Test environment

Item	Value
Backend	backdev (https://backdev.enode.ai/api) — serves the V2 workout DTO. Never test against production.
Portal	NEXT_PUBLIC_API_SERVER=backdev npm run dev from apps/portal (or a static-export build) in a desktop browser; spot-check one narrow/mobile viewport
Tracking	A real iOS or Android device running the Capacitor build for anything involving sensors, video, TTS, keep-awake, or offline; the dev server in a browser is acceptable only for pure-UI cases
Sensors	At least 2 Enode SmartBar sensors, charged — required for the live-training sections (single- and dual-sensor cases)
Tools	Browser DevTools open for portal runs (Console + Network); a case passes only if the UI is correct and no console errors and the relevant request returned 2xx (or a documented 313/31x)

Test accounts & data

• A Pro coach account on backdev with: ≥2 athletes, ≥1 workout template with several exercises, ≥1 scheduled and ≥1 recurring workout.
• A One account (to verify the Pro-app 314 block and One login on the portal).
• An account with restricted privileges (athlete or coach without admin privileges) for RBAC cases.
• A roster CSV fixture for the portal upload wizard.

What a release run is

1. Copy test-runs/_template.md to test-runs/YYYY-MM-DD-<app-or-both>.md.
2. Note build/commit, backend, device(s), tester in the header table.
3. Execute the protocol(s) top to bottom, filling Result (✅ pass / ❌ fail / ⚠️ partial / ⛔ blocked) and Notes per case.
4. Log every failure in the run file's defect log with severity (blocker / major / minor) and console/network detail.
5. Commit the run file. The run file is the proof of what was tested.

Mandatory vs optional: all sections of both protocols are mandatory for a release run, except sections explicitly marked (hardware) may be run once per release on one platform (iOS or Android) if time is short — note which.

Entry / exit criteria

• Entry: release candidate build available; backdev reachable; test data above in place; unit tests + docs:check green on the release branch.
• Exit (release approved): every mandatory case executed; no blocker or major defects open; minor defects triaged (fix or explicitly accept in the run file's sign-off line).

Automation outlook

Cases tagged [automate] in their Notes column are candidates for future Playwright end-to-end tests (stable flows, no hardware dependency). Keep steps deterministic (fixed test data, explicit preconditions) so this stays cheap.