Courier app loses the active order on incoming calls and battery saver
A courier app for a food delivery service runs on Android 10–14 and iOS 16–17. Couriers accept an order, navigate with background GPS, then often receive an incoming call. Beta feedback and crash analytics show that in 18% of sessions where a call arrives during an active delivery, the courier returns to a login screen and the accepted order is lost; on three Android devices the app is also killed when battery saver engages. On iOS, some couriers switch location permission from 'Always' to 'While Using' mid-shift, background tracking silently stops and the customer sees a frozen map. The test lead has eight physical devices, no commercial interruption-injection tool, two weeks, and access to adb on Android and Xcode developer settings on iOS. The product owner wants confidence before a Friday release to 30,000 couriers, and support already reports duplicate orders after the app is killed.
1. Design the interruption test coverage for the courier app. Specify interruption types, order states, platforms and the oracle you would use, and explain why each dimension matters.
Read the worked answer
Use a state × interruption matrix. The defect lives at the intersections, not in either dimension alone.
Order states: accepted/assigned, en route to restaurant, at restaurant, picked up and en route to customer, arrived, delivered-but-not-yet-synced.
Interruptions:
- Incoming call: rejected, answered then returned, answered and kept in the background for two minutes or more.
- Notification or SMS banner, alarm, calendar alert.
- Screen lock, home button, switching to another app, swipe-kill from recents.
- Battery saver on/off, low-battery dialog, device shutdown.
- Network: Wi-Fi to cellular handover, loss, 2G fallback, airplane mode.
- Permission changes: location 'Always' to 'While Using', background refresh off, notification permission revoked.
- OS-level: process death in background, force-stop, kill under memory pressure.
Platform dimension: Android permits a foreground service for tracking, but Doze and battery optimisation can still throttle or kill; iOS suspends the app and gives limited background time, so resume must reconstruct state rather than assume a live process. Test warm resume and cold start after kill separately - they exercise different code paths.
Oracle per cell:
- The accepted order is still present and the courier is not returned to login.
- The backend holds exactly one order record, even after retries.
- Background location resumes within an agreed interval and the customer map unfreezes.
- If state genuinely cannot be restored, the app tells the user explicitly instead of failing silently.
Prioritise the cells implicated by field data, but keep the full matrix for regression.
2. You have two weeks and no commercial interruption-injection tool. Describe a practical, repeatable way to inject these interruptions and record results.
Read the worked answer
Make it repeatable, cheap and evidenced.
Setup: two handsets - the device under test plus a second phone for real calls and SMS (real calls catch OEM telephony behaviour that simulated broadcasts miss). A written script per test: precondition, action, wait time, expected result, observed result, screen recording on. Capture logcat on Android or Console/Xcode logs on iOS for every run; a defect without logs is an argument, not a finding.
Android injection via adb:
- Process death:
adb shell am force-stop <pkg>,adb shell am kill. - Low battery:
adb shell dumpsys battery set level 5,set ac 0; battery saver via settings orsettings put global low_power 1. - Network loss:
svc data disable,svc wifi disable,cmd connectivity airplane-mode enable. - Permission downgrade:
pm revoke <pkg> android.permission.ACCESS_BACKGROUND_LOCATION. - Notification and alarm fakes via
am broadcast; memory pressure via monkey.
Wrap the common sequences in short shell scripts so every run is identical and re-runnable by another tester.
iOS injection: Settings for permission downgrades, Low Power Mode and Background App Refresh off; Developer settings and Xcode for background fetch, network conditioning and simulated location; a second phone for calls.
Because these are timing-dependent races, run each high-risk cell at least three times and record how many of N reproduced. That frequency is also the severity evidence. Automation is optional; repetition and evidence are not.
3. For the Android battery-saver kill, how do you decide whether this is an app defect or expected OS behaviour, and what would you put in the defect report?
Read the worked answer
Separate the OS contract from the app contract.
OS behaviour is expected: Android battery optimisation restricts background work, and since Android 12 foreground-service launch restrictions are tighter. iOS suspends apps. None of that is a defect by itself.
The app defect is failing to meet a requirement under known behaviour:
- The order is not persisted locally, so it cannot be restored.
- The app does not use an appropriate foreground service or background mode during an active delivery, or omits the required notification.
- On resume it does not re-check state or re-acquire location, and gives the user no feedback.
- A retry after the kill produces a duplicate order - an idempotency failure layered on the state loss.
Check the requirement first. If the spec says an accepted order must never be lost, it is a clear defect. If the spec is silent, log the defect anyway (data loss plus duplicate orders is field-visible) and separately raise the missing requirement with the product owner.
Defect report: build; device, OEM and OS version; battery-saver state; order state at the interruption; exact steps or adb command sequence; expected vs actual; frequency (e.g. 8/10 runs); video; logcat showing process death and the restart path; business impact (lost delivery, duplicate order, support calls). Severity is high - data loss plus a downstream duplicate, not cosmetic. Link the duplicate-order defect to this one; they probably share a root cause.