How to test a low-connectivity mining maintenance workflow

“Works offline” is too broad to evaluate a mining maintenance product. A useful test names the device, user, prepared data, field action, attachment, connection transition and replay outcome that the site expects to support.

The result should be a written, pilot-specific boundary. It should show what remains available, what is queued, what is blocked and what the user sees when current server data cannot be confirmed.

Define the exact workflow before testing coverage loss

Choose one bounded job path, such as reviewing prepared work, recording a finding, adding a photo, updating a step and completing a job handover. Name the user role, device model, operating-system version, browser or installed application and the expected starting state.

A general demonstration on a developer laptop does not validate the field workflow. The agreed site device and configuration need to be part of the evidence.

Separate prepared reads from fresh reads

List the information that must be available before connectivity drops. This may include the assigned job, asset identity, approved workflow, known evidence and the current handover state. Then identify information that genuinely requires a fresh server read.

The user interface should distinguish prepared information from data that may now be stale. It should not display an old value as if the system has just confirmed it.

Test each write as a separate operation

A note, measurement, status change, photo and handover are different writes. Test whether each action is available without a connection, how it is queued, whether the user can see its state and what happens if the application closes before replay.

Safety gates and other controlling actions must remain within the site-approved workflow. If an action requires current authority or server state, the product should block it honestly rather than simulate success.

Give attachments their own test

Photos and files behave differently from small text records. Check local preparation, file size limits, retry behaviour, duplicate prevention, upload progress and what happens when connectivity changes halfway through transfer.

Confirm that the final attachment remains connected to the right fault, step, author and capture time after replay.

Cross the connection boundary more than once

A useful field test moves through connected, degraded, disconnected and reconnected states. Repeat that sequence with the application in the foreground, in the background and after a device restart where the supported configuration allows it.

Record what the user sees at each transition. Hidden queues and silent failure create a false sense of completion even when the underlying data model is sound.

Test conflicts and replay ordering

Create a controlled conflict by changing the same record from another authorised session before the field device reconnects. The expected result should be defined before the test. It may reject, merge or ask for review, but it should not silently overwrite a newer decision.

Replay the same queued operation more than once to check idempotency. A retry should not create duplicate notes, photos, handovers or completion events.

Confirm identity and access behaviour

Test session expiry, device lock, sign-out, role changes and what happens when a user no longer has access before queued work returns. Cached information needs the same organisation and role boundary as connected information.

Include lost-device and local-data handling in the technical review. The right answer depends on the supported platform, pilot configuration and customer policy.

Low-connectivity field test sheet

1. Device, operating system, application version and user role
2. Prepared job, asset, workflow and evidence available before disconnect
3. Actions expected to remain available
4. Actions expected to block or show a degraded state
5. Text, measurement and attachment queue behaviour
6. Foreground, background, restart and reconnect transitions
7. Conflict, duplicate replay and ordering result
8. Identity, access and local-data result
9. Final server record compared with the field action log
10. Accepted limitation, owner and rollout decision

Put this test inside a bounded maintenance workflow pilot and use the software evaluation guide to review the broader field, system and governance fit.