# Test brief: fleet and logistics tracking

Product type: fleet and logistics tracking. Vehicle telemetry, routes and delivery proof.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/fleet-tracking/
Printable checklist: https://howtotestaproduct.com/checklists/fleet-tracking/

Run these 8 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: lost-actions). Tool class: browser automation. Usually run by: QA engineer.
   Done when: On the release build, a test vehicle's position appears on the dispatcher map, the driver app shows today's route, a delivery photo uploads, and hours driven with the test vehicle appear in the driver's duty log.
2. penetration testing (risks: data-breach, user-harm, fraud-abuse). Tool class: proxy. Usually run by: external lab.
   Done when: A tester holding one fleet's account and a list of device IDs cannot see another fleet's vehicles or send any command, including engine cut-off, to a tracker.
3. end-to-end functional tests (risks: user-harm, regulatory-penalty). Tool class: browser automation. Usually run by: QA engineer.
   Done when: An immobilise command needs confirmation by a second named manager and is refused while the vehicle reports movement, and the driver's privacy switch stops position updates.
4. security scanning (risks: data-breach, fraud-abuse). Tool class: DAST scanner. Usually run by: security specialist.
   Done when: The scan of the dashboard, driver apps and device API shows no open high-severity finding and no hard-coded device password.
5. compliance checks (risks: regulatory-penalty). Tool class: test management. Usually run by: product manager.
   Done when: A signed review shows the driver notice, the private-use switch and, where hours-of-service logs are offered, each log rule mapped to a screen in the driver app.
6. data integrity and migration testing (risks: data-corruption). Tool class: data validation. Usually run by: developer.
   Done when: After an edit to a driver's duty log, the original entry is still retrievable, the edit shows who made it, and the driver is asked to accept or reject it.
7. device and browser compatibility (risks: lost-actions). Tool class: device cloud. Usually run by: QA engineer.
   Done when: Tracking, log sync and photo capture work on each tablet and phone model in the support list with battery saver on, and unplugging the tablet from the engine module raises a malfunction flag in the driver's log.
8. offline and poor-network testing (risks: lost-actions). Tool class: proxy. Usually run by: QA engineer.
   Done when: Positions, duty-status changes and proof-of-delivery photos captured with no signal upload once and in order when coverage returns.

Acceptance criteria wording:
A release of the fleet tracking platform is accepted when a test vehicle shows on the dispatcher map, the driver app shows its route and a delivery photo uploads, while an account from one fleet cannot see another fleet's vehicles or send any command to its trackers. An immobilise command needs a second named manager and is refused while the vehicle moves. An edited duty-status entry keeps the original and waits for the driver's acceptance, and data captured with no signal uploads once and in order.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.