05 · Quality check

How we prove it works

Critical journeys, regression of every existing page, the new module, the bots, security and the release blockers.

Regression first, every release📄 TESTING.mdVersion 1.0 · 4 October 2026

1Testing Goal

Prove that orders move correctly from intake to dispatch, that stock figures stay exact and explainable, that bots never act beyond their level, and that nothing that works today breaks.

2Critical User Journeys

Airline: New order (Qantas-style PO, MEL) → invoice no. → appears on Production Planning → print → confirm → allocate → schedule (Interstate · MEL · Roadmaster) → dispatch → live stock reduced.

Non-airline: Phone order → availability check → delivery date → invoice no. → print → confirm → one line short → Inform Alex → Stock IN → allocate → schedule (Non-airline) → dispatch.

The release must not ship if either journey is broken.

3Regression — existing app (run every release)

4Orders — intake

5Invoice, print, confirm

6Packing & allocation

8Schedule & dispatch

9Agents (rule-based)

9a. Dashboard & analytics

9b. Hermes Reminder Bot

10AI Order Intake

11Responsive & accessibility

12Security

13Release Blockers

Do not release if: login or existing passwords break · stock figures change without a transaction · dispatch removes wrong quantities · a bot changes stock/orders without approval · existing Plan / Tartlet / Sync pages regress · stock.db not backed up before deploy.

14Test Result Format

Test · Expected · Actual · Device/browser · Steps · Screenshot · Severity · Status