Deliverable exists

The cancelling state is covered as a state in its own right

MUST NOT write cases that assert an outcome for simultaneous arrivals

The five finished states are used as starting points

MUST NOT model the scheduler's internal phases as states

All 45 state/input combinations accounted for

Both timeouts and both give-up paths are distinguished

Expected results come from the run page or the API

Deliverable exists

Both finished statuses are used as starting points for every scan type

MUST NOT ship the journey walk as the pack

All 20 status/scan combinations accounted for

Mis-scans on a live parcel are covered

The hub self-scan is modelled as a transition

Expected results are what the public tracking page shows

Deliverable exists

The submitted application is attacked through routes the UI does not offer

MUST NOT record 'the button is not shown' as the expected result

Undefined behaviour is raised as questions, not answered

All 24 state/event combinations accounted for

Back is exercised from every step that has one

Save and exit is modelled as a transition on every step

Expected results are observable to the applicant

Deliverable exists

All 30 status/event combinations accounted for

The cancelled subscription is attacked with every event

Paused rejects the payment events

Transitions that keep the same status are modelled

Expected results are observable to the tester

MUST NOT ship a pack made only of things that work

Deliverable exists

MUST NOT invent balance-derived situations

Events that leave the situation unchanged are modelled as transitions

Redemption is modelled with its outcome depending on the amount

The two incidents are covered as refusals with their situations seeded

All 40 situation/event combinations accounted for

MUST NOT sweep a row of refusals into one case

Every case states starting balance and per-step balance

Deliverable exists

The model is built on the seven visible situations

MUST NOT assert on database state

The two indistinguishable codes are called out

Events that must be refused after the money moves

All 42 situation/event combinations accounted for

Transitions that keep the same label are modelled

Each case is runnable from the two screens alone

Deliverable exists

Approving is modelled as two distinct entries with different outcomes

The first approval has its own case asserting the contract did not move

MUST NOT collapse the two approvals into a single unasserted step

Actions that must be refused are covered

All 36 status/action combinations accounted for

The approval count is a stated precondition and its reset is exercised

Every step names the status the tester should see

Deliverable exists

Coverage is counted against transitions, not situations

MUST NOT let reaching every situation stand as the coverage claim

The lead's claim is answered explicitly

Answers posted outside the working situation are covered

All 28 situation/event combinations accounted for

The window closing is exercised from the paused situation

Cases are runnable steps with per-step expected situation

Deliverable exists

Statuses reachable by more than one route are identified with their routes

Cases run a route in followed by the next event

MUST NOT present one end-to-end walk as the coverage

MUST NOT dump every possible two-step sequence

Events that must be refused are covered

All 35 status/event combinations accounted for

Clock expectations are stated per step