IoT device testing for connected products and device fleets
Test connected devices across firmware, network conditions, services and changing environments.
Midair keeps device state, test configuration and runtime evidence connected, so failures can be reproduced and compared across runs.
An IoT failure rarely belongs to one component.
A connected device may work correctly in isolation and still fail once firmware, hardware, networks and external services interact.
Detecting that something failed is often the easy part. The hard part is recreating the exact conditions that caused it.
Network conditions change
Latency, connectivity, routing or temporary interruptions can change device behavior between runs.
Device state changes
A result may depend on firmware version, configuration, previous actions or the physical state of the device.
External systems are involved
APIs, services and other devices can affect the same scenario.
Fleets are not identical
Different device models, firmware versions and configurations create different failure conditions across the same product.
Keep the connected-device test in one context.
Midair connects code analysis, distributed testing and runtime evidence across the IoT testing workflow. The platform is built around Visao, TS Factory and Delta feeding their results into Midair.
Before the run
Analyze · Visao
Check source code and project-specific rules before the firmware runs on the device.
During the run
Test · TS Factory
Run scenarios across devices, hosts and services while recording the environment behind each result.
While devices run
Observe · Delta
Collect logs, events and runtime data from connected systems during execution.
Everything together
Investigate · Midair
Review a failed run together with its firmware, device state, configuration and runtime evidence.
Compare it with later runs after the software or environment changes.
What IoT device testing can cover
IoT systems combine physical devices with software and communication infrastructure. Testing becomes most useful when these parts are evaluated together.
Device and firmware behavior
Test how firmware behaves on the target device across different states and configurations.
Connectivity
Reproduce scenarios involving changing network conditions, communication failures and reconnections.
Device-to-service communication
Test behavior where devices depend on APIs, backend services or other remote systems.
Updates and configuration changes
Compare device behavior across firmware releases, deployments and configuration changes.
Multi-device scenarios
Coordinate tests where several connected devices participate in the same workflow.
Long-running behavior
Run scenarios over extended sessions where failures may depend on accumulated state or changing conditions.
A connected-device failure needs its environment.
A pass or fail result alone does not explain why an IoT scenario behaved differently.
For embedded and connected systems, reproducibility means preserving the conditions around the run as well as the test itself. Interpretica's engineering notes treat device state, host environment, network, power and inputs as part of reproducible embedded testing.
TS Factory was designed around distributed environments and multi-agent testing, including setups where several machines are required to test one device.
A useful test record can keep together:
Firmware version
Know which build was running on each device.
Device state
Keep the relevant configuration and device context with the result.
Network environment
Track the conditions surrounding the communication path.
Test hosts and services
Record the other systems involved in the scenario.
Runtime evidence
Keep logs, events and measurements with the run that produced them.
Comparison between runs
See which condition changed when behavior changed.
Where this becomes useful
Connected products
Test devices whose behavior depends on firmware, networks and remote services.
Device fleets
Run the same scenarios across multiple devices while preserving the context of each result.
Industrial IoT
Investigate systems where devices, controllers and services operate together over long periods.
Gateways and networked hardware
Coordinate tests across gateways, routers and connected endpoints.
Difficult field failures
Recreate behavior that appears outside the development environment and is difficult to reproduce in the lab.
Why Midair fits connected-device testing
IoT failures often span more than one device or software layer. Firmware, network conditions, remote services and device state can all affect the same test scenario.
Midair keeps that distributed context together, making it easier to compare runs and understand which part of the environment changed.
From our engineering work
Embedded testing diary #1: Device fleets
Managing heterogeneous device setups, multiple test hosts and resource contention in embedded testing.
Embedded testing diaryEmbedded testing diary #2: Reproducible tests
Why device state, network conditions and the surrounding environment need to be preserved between runs.
Start with one connected-device failure.
Bring one device, one firmware build and one scenario that is difficult to reproduce.
Connect the environment to Midair, preserve the conditions behind the failed run and compare the result as the software or setup changes.
Community
€0
Run Visao and TS Factory on a shared instance and review the findings.
Most popularPro
€90per month
Your own Midair instance for the team, with Delta, MCP and AI analysis of results.
RecommendedBusiness
€990per month
Add SBOM and vulnerability analysis, team performance metrics and self-hosted instances.
For complex environmentsEnterprise
Custom
Adapt Midair to a large-scale, embedded or regulated environment.
Compare the plans and pick one on the pricing page. Prices are monthly, in euros.