Test offline school software by separating three questions: what can be viewed without a connection, what can be recorded locally, and what has actually reached the server. Complete a permitted task, restore connectivity and retrieve the saved record in a fresh authorized view. A screen that remains open offline does not prove that a new entry has been synchronized.
This is an acceptance checklist for school administrators in Bangladesh. It is published by iilmaa. The suggested tests are evaluation scenarios, not a claim that every iilmaa screen or device supports offline operation.
Define the exact device and workflow
Write down the device, application, account role and task before disconnecting. A native mobile app, a browser tab and an installed web app may behave differently. Support for one attendance action does not establish support for fee collection, exports or administration.
Ask the supplier to identify the supported offline actions and their limits. Record the product version and test date. If a required action is unsupported, include a practical fallback in the school’s operating procedure rather than asking staff to guess during an outage.
Review the attendance workflow and attendance feature overview when preparing an iilmaa demonstration. Confirm behavior on the actual application your staff will use.
Separate viewing, local recording and server confirmation
| State | What the evidence can establish | What it does not establish |
|---|---|---|
| Previously loaded roster remains visible | Some information is available locally | The list is current or new entries will save |
| A local entry is accepted | The application reports a local action | Another device can retrieve that action |
| A synchronization attempt begins | A transfer is being attempted | The server accepted the record |
| A fresh authorized view retrieves the result | The record is available through that view | All other queued entries are resolved |
These states should be understandable to the person doing the work. Ask the demonstrator to explain any pending, failed or conflicting item without relying on technical logs that ordinary staff cannot access.
Run a controlled attendance scenario
Use fictional students and an isolated demonstration environment. Begin with a small roster whose current values are known. Keep the date, class and account scope unchanged unless the test specifically covers changing them.
- Load the permitted attendance workflow while connected.
- Disconnect the device using the demonstration’s agreed method.
- Record a small number of supported actions and note the displayed state.
- Leave and reopen the relevant view using the supported procedure.
- Restore connectivity and inspect unresolved or failed items.
- Retrieve the results from a fresh authorized view and compare them with the expected register.
If the test fails, keep the original evidence and establish what remains unsaved before repeating the action. Repeatedly tapping a save button is not a useful recovery procedure unless the product documents that behavior.
Check identity and correction boundaries
Ask what happens if the staff member signs out, changes an institution or branch, or loses permission before pending work is sent. Pending records must not silently move to another account’s context. These are acceptance questions; do not change a live institution’s permissions simply to run a demonstration.
Separately test an authorized correction after synchronization. Verify the final value and the available correction history. A successful first submission does not prove that conflicting edits are understandable or recoverable.
Keep a small test record
For each scenario, record the starting state, action, observed message, expected saved result, actual retrieved result and unresolved question. Include the device/application version and the reviewer. A short, specific record is more useful than a general note saying “offline works”.
The school’s fallback should name the temporary register, responsible staff member, later reconciliation step and final reviewer. Do not assume that a payment has been confirmed because a local receipt-like screen is visible: payment-provider confirmation and settlement require their own evidence.
Compare the application’s limitations with your school’s operating requirements and the quoted package. Connectivity is one procurement criterion, alongside permissions, data export, training and support.
Frequently asked questions
If a page opens without internet, does that mean the application works offline?
It shows that the page or some data is available locally. You still need separate evidence for supported local writes, synchronization, corrections and retrieval of the final saved records.
Can we assume fee payments work offline because attendance does?
No. Evaluate each workflow separately. A locally recorded action does not establish payment-provider authorization, successful processing or settlement. Ask for a demonstration of the actual payment confirmation process.
What is a useful pass condition for an attendance test?
The agreed supported actions produce the expected saved register, a fresh authorized view retrieves those results, and unresolved or failed items are visible with a documented recovery procedure. Define the exact scenario before deciding whether it passed.
Ask for a workflow-specific iilmaa demo using the devices and connectivity conditions your staff expect to encounter.