Mobile Test Design

A long press is a distinct input event that opens behaviour a tap never reaches: a context menu, selection mode, a drag handle. A tap case proves only the primary action, so the held gesture needs its own case.

Handheld users choose when to update, and many devices stop receiving platform updates entirely, so the installed base stays spread across several version lines for years. A suite that runs only on the newest line leaves most real users unverified.

Declare the link as an input: a named profile with fixed added delay, loss rate and bandwidth cap, applied at one controlled point in the request path. Then assert product behaviour under that profile, not raw elapsed time.

Assert three times: while disconnected, that the action is locally accepted and marked pending; at reconnect, that delivery starts unprompted; once drained, that the far side holds the work and the device now matches it.

Assert the in-progress input survives: values already typed, the selection, the scroll region, any open dialog, and the step of the flow. Rotation rebuilds the screen, so a case that only checks it still renders proves nothing.

Three answers produce three different application behaviours: the feature works, the feature degrades and may ask again, and the feature must degrade with no prompt ever appearing. Only the third exposes the silent dead ends.

Coverage must prove the previous app version still works against the backend the new one requires. Run both versions' suites against the same deployed service in one pass, and cover a user who updates partway through a flow.

Eventual success only proves the happy path survives slowly. Assert what the user sees meanwhile and on failure: a progress surface, a control that cannot fire twice, a notice naming the next step, and typed data preserved.

Capture the values the device holds before disconnecting; that snapshot is the oracle. Stale-but-allowed means the screen matches it and says it is not current. Wrong means values never held, missing promised content, or stale data shown as live.

Larger text reflows the layout: everything moves, wraps and grows, so a coordinate no longer identifies the element. Assert on identity and content instead — the element is present, reachable, holds the expected text, and is not drawn cut off.

The prompt belongs to the platform, not the product. Its wording and layout are decided outside the application, it may not appear at all when a decision is already stored, and it takes focus away from your own screens.

They are different artefacts. The shipped build is optimized, has unused code stripped, is signed with the release identity, drops test hooks and verbose logging, and points at production configuration — so code the test build kept alive can vanish from it.

Everything the skipped screens would have produced: a signed-in user established programmatically, a target record seeded for this run, any first-run or consent flags those screens write, and a link built from that seeded record.

Declare the gesture in terms the case owns: endpoints as fractions of the target element, a stated direction, and an explicit contact duration. Recorded pixel coordinates and default speeds differ per device, so one script runs a different gesture.

Force the termination deliberately rather than waiting for it, re-enter through the path a returning person takes, and assert the rebuilt screen carries the same record and the same answers - while checking that nothing half-finished silently resumes.

A top-tier-only suite never sees failures caused by scarcity: the app's process reclaimed while in the background, cold starts slow enough to expose races, memory limits hit on large content, and a device slowed to shed heat.

Presence in the element tree is not the same as being touchable. A contact is delivered to a screen coordinate, so an element scrolled out of view or covered by a fixed bar receives nothing, or the wrong element does.

Control the moment: hold the response at a stand-in the run owns, switch the connection, then release. Assert the ambiguous outcome resolves - one definite result on screen and exactly one matching effect recorded on the server side.

Four things: how the divergence was constructed, which value the written rule says survives, what became of the losing edit, and that device and far side agree afterwards. Assert the recorded rule, never the behaviour you happened to observe.

Assert the whole degraded journey: the fallback appears, explains what is unavailable, and can be completed to a real end state. Then assert what must not happen — no repeated prompting, no empty screen passed off as success, no dead controls.

Re-cut it from field evidence rather than habit: usage-weighted share across version lines, capability tiers and screen classes, and which rows have ever caught a failure nothing else caught. Every re-cut costs comparability, so change it on a decided cadence.

Check that the flow resumed at the same step with the same entered values, that nothing advanced or re-sent itself while the app was inactive, that countdowns and media behaved as specified, and that nothing sensitive was left exposed.

Screen size and device capability vary independently: large low-cost displays and small powerful devices both exist. Layout failures — clipped labels, controls out of reach, a keyboard covering the focused field — track the screen class, not the hardware's speed.

Only that the touch path works. Keyboard and pointer input arrive as different events - hover, secondary click, key repeat, an arrow-key caret - and reach code the touch path never runs, so gesture-only actions stay unexercised.

The unsynced-work indicator is the only report a user gets about work that has not left the device, so it is a promise, not instrumentation. A case asserts it rises, holds while work is outstanding, and clears only on success.

Test the boundary and the ways around it: at the minimum version, one below it, and with the version check unreachable. The decisive case asserts the service refuses a blocked client, since a screen the app draws can always be skipped.

Stand a programmable element in the request path that answers every call with a sign-in page instead of the expected payload. Assert the app rejects the impostor response, points the user at the network, and caches nothing.

Split-screen halves the available width and can resize the app while it runs, so layouts assuming a fixed full-screen size, permanent focus, or exclusive use of hardware break. Test at the narrow size and while the divider is dragged.

Take the permission away between two uses of the feature inside one case, then assert the second use lands on the degraded path rather than erroring or hanging. Products fail here by checking once at launch and caching the answer.