ZeuZ
IoT testing

IoT testing from the device to the cloud, in one test.

IoT testing in ZeuZ runs the device, the companion app and the cloud in one test: a Python node on the hardware or gateway, Appium on the phone, REST and WebSocket checks on the API, and database assertions at the end. One flow, one report, evidence for every step.

Device & firmwareGateway & protocolCompanion appCloud APIData
node-toronto-01atlas-crmrelease/2026.09
Test case · Thermostat setpoint reaches the cloud
Passed
5 / 5
Steps passed
3
Surfaces
1m 54s
Duration
DeviceSet thermostat to 21.5 °C from the device node✓ Passed
bash · node-rpi-lab-02 · set_temp.sh 21.5 → exit 0
AndroidConfirm setpoint in the companion app✓ Passed
Appium · Pixel 8 · tap Thermostat › Living room → shows 21.5 °C
WebSocketAssert setpoint event on the stream✓ Passed
event: setpoint_changed · value: 21.5 · device: therm-0042
APIGET cloud API device state✓ Passed
GET /devices/therm-0042 → setpoint: 21.5 · 200 OK
DataCheck telemetry row landed✓ Passed
PostgreSQL · SELECT … telemetry WHERE device=therm-0042 → 1 row
Device steps on node-rpi-lab-02 · in your labrelease/2026.09
In one paragraph

IoT testing is the verification of a connected product across every layer it runs on: the device or firmware, the gateway and protocol, the companion mobile app, the cloud API and the data it lands in. ZeuZ tests all of them in one flow, with a Python-based node that runs on the device or beside it, Appium for the app, REST and WebSocket actions for the cloud and database assertions for the result.

Part of ZeuZ Test Studio · Device and firmware, gateway and protocol, companion app, cloud API and data, in one flow
The problem

Where IoT testing breaks today.

Firmware, app and cloud are tested by three teams with three tools, and the defect lives in the handoff none of them owns.

Field failures are connectivity failures, and the lab never tests what happens when the link drops and comes back.

The device is the one thing a SaaS testing tool cannot reach, so device checks stay manual and release day stays long.

The six steps

How ZeuZ automates IoT testing.

  1. 01Test designProposes the device, app and cloud cases a firmware or app change needs, ranked by what the release touches.
  2. 02Test case creationDescribe the scenario in plain English, from device action to cloud result; ZeuZ writes it as one case.
  3. 03Test automationDevice steps through scripts on a Python node, app steps through Appium, cloud steps through REST, WebSocket and SSE actions, database checks at the end.
  4. 04Test executionRuns on nodes on the bench, on the gateway, on a Raspberry Pi-class device or in the lab, on a schedule or a firmware-build webhook.
  5. 05Reporting and analysisEvery step returns its evidence, so a failure says whether the device, the link, the app or the cloud broke.
  6. 06Test maintenanceApp UI changes come back as proposed repairs; device and API steps are versioned with the firmware branch.

Your team reviews what ZeuZ produced. Nothing joins the suite or runs without a person accepting it.

See it in the demo lab or in your own environment

See it run on your application.

Watch a device, its companion app and its cloud API verified in one live run.

What is covered

IoT testing tools across the stack.

ZeuZ Node is written in Python and runs on Windows, macOS and Linux, including Raspberry Pi-class devices, so a node can sit on the bench next to the hardware or on the gateway itself and execute scripts and shell commands during a run. Custom protocols are handled through Python scripting inside the test; the cloud side is tested through REST, SOAP, GraphQL, WebSocket and server-sent-event actions with authorization headers, client certificates and JSON schema validation.

Companion apps run through Appium on real Android and iOS devices, emulators and simulators, with ADB for device-level control, and results are asserted in PostgreSQL, MySQL, MariaDB, SQL Server, SQLite or MongoDB. Every layer runs in the same test case, and the report shows which layer failed, which is what IoT testing in one suite means in practice.

Device side
Python node on Windows, macOS, Linux and Raspberry Pi-class hardware; scripts and shell during a run
Protocols
REST, SOAP, GraphQL, WebSocket, SSE; custom protocols via Python
Companion app
Appium on Android and iOS, real devices and emulators, ADB
Data
PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB
Triggers
Manual, schedule, firmware-build webhook
Deployment
SaaS, on-premises, air-gapped lab
Firmware update flowsProvisioning & pairingConnectivity failoverTelemetry integrityCompanion appCloud API

Runs where your code is allowed to be.

SaaS

Hosted by ZeuZ, execution on your own machines.

On-premises

Point the client at your own server.

Air-gapped

Disconnected environments, scoped per engagement.

Runs inside Jenkins, GitHub Actions, Azure DevOps, CircleCI and Bitbucket; results into Jira, Slack and Teams.

Related capabilities

Works in the same suite as.

Mobile test automation

Native and hybrid apps on real Android and iOS devices, emulators and simulators.

Mobile test automation →
API test automation

REST, SOAP, GraphQL, WebSocket and SSE actions with auth, schema validation and extraction.

API test automation →
End-to-end testing

One case that crosses the device, the app, the API and the database.

End-to-end testing →

Read next: IoT testing automation: how ZeuZ handles smart devices and protocols →Related: See pricing →

FAQ

Questions about IoT testing.

Ready to automate QA testing today?

See ZeuZ Test Studio write, run and repair tests against your own application code.

or explore our services →
Book a demo