Test Plan

This plan covers integration testing of TrafficGrid end to end: the two user-facing clients and the backend they share. Results are recorded on the Test Tracker.

TrafficGrid has been built in many separate pieces. These tests check that the pieces work together, and they also show which features are not yet joined up.

Scope

Section	ID prefix	What it covers	How it runs
Web console	WEB	Every screen and action of the staff console, for each role that can use it	Manual
Citizen mobile app	MOB	Every screen of the citizen app, plus journeys that start in the console and end in the app	Manual
Backend API	API	Behaviour no UI exercises: authorization on every endpoint, validation, and side effects between services (audit entries, notifications, fine status changes)	Automated

Each case covers one of:

• Happy path: the feature works for a role that is allowed to use it.
• Validation and negative cases: bad input is rejected with a clear message.
• Role boundaries: a role without the permission cannot see or use the feature, and the API refuses it.
• Effects between services: an action in one service shows up where it should in the others.

Out of scope for now: parking tickets and the parking officer role, the officer mobile app (not built yet), and external integrations.

Environment

All testing runs against the local Docker Compose stack, with the local database profile enabled, and every request goes through the API gateway. Each recorded result names the environment it ran in, so other environments can be added later without changing the format.

Test users

Users are always referred to by role, never by account details. The roles in scope are:

Role	Uses
CITIZEN	Mobile app only. Refused by the console.
ZRP_OFFICER	Console: fines and vehicles for law enforcement
COUNCIL_OFFICER	Console: fines and vehicles for the council
AUTHORITY_ADMIN	Console: administration within one organisation
SUPER_ADMIN	Console: everything, including system configuration

The staff roles are seeded by the auth service's database migrations for local development. Citizen accounts are created through the app's sign-up, which is itself a test case. Credentials are never written on this site.

Case conventions

IDs

Case IDs look like SECTION-FEATURE-NNN, for example WEB-FIN-003. An ID never changes once published. A case that no longer applies is marked retired, never renumbered or deleted, so links and bug reports keep pointing at the right case.

Fields

Field	Meaning
id	Stable ID, as above
section	web, mobile or api
feature	The feature the case belongs to, for example "Fines"
title	One line saying what is being checked
preconditions	State and test data needed before starting
steps	Ordered list of actions
expected	The observable result that counts as a pass
priority	P1 (must work; the smoke pass), P2 (important), P3 (minor)
roles	Roles the case applies to
services	Backend services the case touches, to point a failure at the right service
mode	manual or automated
blockedReason	Optional. Set when the feature is not wired to the backend yet
retired	Optional. true hides the case from the tracker

Blocked cases

A feature that still reads mock data, or is not connected to the backend, is still catalogued. Its case gets a blockedReason and shows as Blocked until the feature is wired up and someone records a result. This keeps the tracker an honest map of the integration work that remains.

Known defects

Cases always describe the correct behaviour. If the system does not behave that way yet, the case fails and links to a bug, rather than being reworded to match what currently happens.

Security cases

Security cases describe only the expected secure behaviour, for example "a request without a token is rejected". Details of how a weakness could be exploited go in the private bug report, never on this site.

Results

Statuses

Status	Meaning
Pass	Behaved as expected
Fail	Did not behave as expected; a bug link should be recorded
Blocked	Could not be run: the feature is not wired up, or a dependency is broken
Skipped	Deliberately not run this time
Not run	No result recorded yet

Where results live

The tracker reads three files, all kept in this site's repository:

File	Contents	Written by
test-cases.json	The case catalogue	Whoever adds or changes cases
results.json	Latest manual result per case	The project lead, from the tracker
results.automated.json	Latest automated result per case	The automated integration test suite

Each result records status, tester, date (an ISO 8601 timestamp), environment, notes and bugLink. Only the latest result per case is kept, and earlier results remain in the repository's history.

When a case has both a manual and an automated result, the tracker shows the later one, and marks it 🤖 if it came from the automated suite. If both have exactly the same timestamp, the manual result wins.

Recording manual results

1. On the Test Tracker, choose Edit results. Check the tester name and environment at the top.
2. Open a case, run it, and set its status. Add notes, and a bug link for failures. Setting a case back to Not run removes its result.
3. Edits are kept as a draft in your browser, so reloading the page does not lose them. Edited cases are marked "Unsaved edit", and the progress counts include them straight away.
4. Choose Export results.json and commit the downloaded file as docs/testing/data/results.json. The site redeploys with the new results, and the draft clears itself once the published file matches it.

Nobody else sees a draft until the exported file is committed. If the browser blocks storage, the tracker still works but warns that the draft will be lost on reload, so export before leaving the page.

Automated results

The backend API cases are run by a separate integration test suite. Each automated test is tagged with its case ID, and every run writes results.automated.json, which is committed here like any other change.