An OSH inspection app: what to test in the field, with poor coverage and during synchronisation
Inspections do not always take place beside a reliable network. They may involve a basement, a remote installation or a building with inconsistent coverage. An OSH app should therefore be evaluated using the devices, connectivity and conditions the team will encounter at work.
A website adapting to a mobile screen does not demonstrate offline capability. Offline availability, its scope and synchronisation must be confirmed for each solution and configuration. This article proposes procurement tests; it does not attribute these features to a particular product.
Define a representative inspection
Select a short route including area identification, checks, a finding and a photograph without personal information. The entry on safety inspections helps define the purpose. Add an action and an owner so that the test extends into follow-up.
Use a realistic form and a normal work device. Check control sizes, daylight legibility and how easily an answer can be corrected. If the task requires gloves, test interaction in a safe environment under the intended conditions.
Establish what offline work actually means
Ask what needs downloading before departure: forms, sites, equipment, users or case files. Then disconnect the network and complete the whole route. A form that opens offline may still need internet access to attach images or retrieve mandatory information.
- Create and save a new inspection without coverage.
- Interrupt the application and recover pending work.
- Add, remove and reopen a photograph.
- Change an answer before synchronisation.
- Clearly identify data that remains only on the device.
Use fictional information for these tests. Record observations and distinguish an available function from a proposed manual workaround. Either may suit a particular context, but they should be evaluated against different criteria.
Test imperfect synchronisation
Restore connectivity intermittently during upload. Check whether the system identifies pending items, allows retries and avoids duplicate records. Review forms and attachments separately: an inspection visible in the office may be incomplete if its photographs have not arrived.
Also test a simultaneous change to the same case from another device. The solution should explain how it handles the conflict and who decides when necessary. Seeing the final data “appear” is insufficient evidence; examine what happened to the previous version.
An example of test acceptance
In an illustrative scenario, a safety professional records five checks and a photograph without coverage. She closes the application, reopens it and confirms the draft remains available. Back at the office, she synchronises and another user verifies content, attachment, authorship and status.
The upload is then repeated to check that a second inspection is not created. Finally, an action is created from the finding and its link to the source is reviewed. The acceptance criterion describes this complete result instead of simply stating “works offline”.
Review the device and locally stored information
IT should assess sessions, device protection and locally stored data. Ask what happens when a device is lost, a user logs out, another person signs in or permissions are withdrawn while the device remains disconnected.
These matters connect to digital evidence and the NCSC cloud security principles, including user management and secure service use. Review the app and platform as one workflow alongside the company’s device policy.
Keep the test record specific to the configuration used: device model, application version, connection conditions and relevant settings. If a material update changes the workflow, the same scenarios provide a focused way to check that essential behaviour remains suitable.
Measure the whole job
Observe the effort required to record, correct, synchronise and review an inspection. Include subsequent office work: classifying findings, assigning actions and checking evidence. Saving taps in the field adds little if it creates repeated manual tasks on return.
Include someone unfamiliar with the demonstration in the final review. Ask them to identify which inspection is complete and which action remains outstanding. Their answer will reveal whether the interface communicates status clearly enough for handovers between shifts and teams.
Connect the test to action follow-up and the IT security review. When exploring Sabentis, bring your inspection route and confirm the mobile and offline scope available for your case through a documented end-to-end test.
Acceptance checks for mobile field work
Alongside connectivity, test the small interruptions that occur during a real working day. Record expected and observed outcomes so that defects, known limitations and training needs can be distinguished before procurement decisions are made.
- Change screen orientation and text size while completing the form with fictional information during the test.
- Simulate low battery and check what the user is told about the last save and any pending data.
- Interrupt an attachment upload and compare the status shown to the field user with the office view.
- Test similar equipment or area names to check whether an inspection can easily be assigned to the wrong asset.
- Ask someone other than the demonstrator to recover a draft using only the help available to normal users.
Frequently asked questions
What should happen when a photograph fails to synchronise?
Acceptance criteria should require a recognisable failure and an identifiable pending attachment. Also check whether the reviewer can see that the inspection is incomplete. A successful-upload message is insufficient when only the form has arrived and its supporting photograph remains on the device.
Can inspections be carried out on a shared phone?
That arrangement can be considered, but it needs specific tests for user switching, drafts and record attribution. IT should confirm device and data protection. Check that the next person does not inherit an active session or information they do not need for their role.
Is testing flight mode during a demonstration enough?
It is a starting point, but it does not represent every interruption. Include connection loss during saving and image upload, followed by recovery. The aim is to establish what the user must do when the normal workflow is interrupted.
How can two apps with different offline behaviour be compared?
Use the same route and assess the complete task: preparation, recording, recovery, synchronisation and review. Record any manual steps required by each option. This reveals actual operational effort without treating a marketing label as evidence that the products behave identically.
Sources and methodology
- NCSC: cloud security principles: United Kingdom: technical guidance for evaluating security and responsibilities in cloud services.
- NIST SP 800-124, revision 2: United States: technical guidance on securing and managing mobile devices throughout their lifecycle; it does not certify app functionality.
Sources consulted on 6 October 2026. The practical checklist proposes management checks; its application should reflect each organisation’s scope.
