Multi-Device Testing

The problem

Your most important flows are not one-person jobs. A user sends a message and someone else has to receive it. A user sends a payment and someone else has to get paid. A patient books an appointment and a doctor has to see it. Someone places an order and a driver has to pick it up.

Every testing tool on the market runs one device at a time. You can verify the sending half of the flow and nothing else. The receiving half, the part your user actually cares about, gets checked by hand with a second phone on the desk, or it does not get checked until someone files a bug.

It is a strange gap. The industry spent years making single-device tests faster and less brittle while the two-sided flows carrying the most product risk stayed manual.

Today Autosana runs one flow across two devices at once. One agent, two phones, one test. This is true end-to-end testing, and nobody has done it before.

How it works

1. Set the device count

In the flow editor, open Advanced options and set Number of devices to 2. Then write instructions that name Device 1 and Device 2 directly:

On Device 1, switch the app to light mode. On Device 2, switch it to dark mode.
Verify that each device keeps its selected theme.

The agent sees both screens and takes one action at a time, on Device 1 or Device 2, choosing which device to act on as the flow progresses. Code-managed flows work the same way through the .autosana schema. If you add a multi-device flow to a suite, every flow and Auth Instruction in that suite must use the same device count.

2. Pick a model and OS for each device

You choose the device model and OS version for each device when you start the run. Both devices run the same app build and platform, but nothing beyond that has to match, so you can put different models or OS versions on each side. The same ordered device selection works everywhere Autosana runs: the Runs API, MCP run tools, Automations, and GitHub Actions.

3. Review both sides in one run

The run viewer shows both screens and identifies the device used for each action. Logs, performance data, network data, recordings, and other artifacts are separated by device where available. Through the API, results return ordered device metadata and a device_index for every device-specific action, so a failure points at a specific device, not just a specific step.

What this changes for your team

Messaging and chat. Send a message on Device 1 and verify it lands on Device 2, in one run, with both sides recorded.

Payments and transfers. Trigger a payment on one side and confirm it hits the other.

Booking and scheduling. Book an appointment as the patient and see it populate on the doctor's screen.

Delivery and dispatch. Place an order on one device and watch the driver receive it on the other.

Anything with shared state. Sharing, collaboration, and any workflow where an action on one device is supposed to change what another device sees.

Teams have been checking these flows by hand because there was no other option. Now they run on the same schedule as the rest of your suite: nightly, in CI, or through the API.

A few things worth knowing

Multi-device testing is an advanced feature. A few boundaries to know before you build flows around it:

• A flow can use at most two devices, and both must be cloud mobile devices.
• Both devices use one app build and one platform.
• Both devices must be virtual or both must be physical. The two cannot be mixed in one run. See Real device testing for physical-device availability and requirements.
• State caching is disabled for multi-device runs.
• In a suite, all flows and Auth Instructions must use the same device count.