Why Is Beyond End-to-end Testing for IoT Devices Important?

It’s become a fairly well established stereotype that people in many parts of the world can’t or won’t look up from their smartphones. Back in the day, the only reason to look at or think about your telephone was because it was ringing or because you intended to make a call fairly imminently.

As a consequence, if a signaling error was preventing your home phone from completing calls as intended, you might not even notice for a few days. Nowadays, on the other hand, if your LTE service is interrupted for two or three minutes you’ll probably notice immediately—and you’ll be none too happy about it.

These devices are increasingly present in our smart factories, homes, and automobiles, and they’re based on a principal of constant communication. If your smart oven loses connectivity while it’s in use, for instance, it immediately presents a real fire hazard.

If your automobile’s eCall service cuts out, it could be a matter of life and death. As a result, device testers in this emerging field have their work cut out for them.

Device/Protocol Diversity

Because service verification standards in the world of the IoT are so stringent, device testers need to tailor their efforts to the specific challenges that the IoT presents. Chief among these challenges?

The tremendous amount of hardware and software diversity among these devices. Mobile phones have been trending towards market fragmentation for a while now, with more unique Android and iOS phone models coming out every year—but they’ve got nothing on the IoT.

Yes, 3GPP has set its NB-IoT standard for how these devices should interconnect with LTE, but that doesn’t mean the interplay between each network element has been entirely standardized.

The devices themselves vary significantly, and a wide variety of different platforms, apps, and GUIs all have to work together to create appropriate service even after connections have been established to the application server and EPC framework.

And while diversity and interoperability are critical concerns for testers, they’re also not the only factors adding complexity to testing for IoT devices. There’s also the sheer number of communication protocols and design layers that go into even a straightforward-seeming device.

Depending on the device and the device maker, you might be looking at Constrained Application Protocol (CoAP), Extensible Messaging and Presence Protocol (XMPP), Message Queuing Telemetry Transport (MQTT), or other unique protocols that have vastly different standards for conformance.

Not only does this raise the bar for the amount of domain knowledge required to test a variety of devices effectively, it also increases the potential number of test scenarios even further.

Beyond End-to-end

All of these moving parts mean that while a test case that measure the success or failure of a particular action might not tell you everything you need to know. If a car’s emergency call service connects to the wrong call center or doesn’t connect at all, that doesn’t automatically tell you the layer at which the issue occurred.

This is where signalling protocol analysis and access to the network elements under test come into play. Though these aren’t traditionally within the scope of end-to-end test flows, in the case of IoT devices they may prove particularly impactful for turning bugs found into bugs fixed.

Thus, where an end-to-end test might require access to the various endpoints—whether that’s smartphones or application servers—an IoT test flow that went beyond end-to-end would include signal analyses of the sort we discussed above that could point testers to the root causes of service gaps on a much more granular level.

If a test case involved a user using an Android smartphone to ask a smart refrigerator if she was out of eggs, for instance, a test that went beyond end-to-end might give a clearer suggestion of whether the test failed because the IoT device lost its LTE connection or if the API malfunctioned.

This adds value for engineers when it comes time to address the test results—but it does potentially make the tests more complicated, which can slow things down in test environments that already don’t allow manual testers to power through more than half a dozen or so use cases per day.

Constant Communication

Okay, now we’re going to move the goalposts a little bit farther. We mentioned in the opening paragraph that IoT devices function based on a principal of constant communication—but what implications does this have for testers, exactly?

For one thing, it greatly increases the importance of regression testing. Especially when it comes to things like emergency calling protocols for automobile accidents, it’s not enough to do a “one and done” round of testing—instead, you need to follow up on a consistent basis to ensure that everything is still working properly.

The trouble here is that testing these devices ahead of a release is already going to require a huge outlay of resources, for exactly the reasons outlined above. The more complex these test cases become, the more time and effort they require of testers.

Once you add 24/7 regression testing to the mix, the engineer resources required become even more considerable. For this reason, the IoT may be one of the first areas to emphatically embrace automated testing. Automated testing in this context would, of course, mean orchestrating ongoing tests using the IoT devices themselves and other network elements.

Testers would use a repeatable framework that could be adjusted to meet the needs of different test cases, helping to reduce the need for engineers to devote huge swaths of time to never-ending tasks like regression tests. In this way, automated tests could potentially increase the number of test cases verified per day by a huge percentage.

Considering the proliferation of different potential use cases in the IoT realm, improved testing velocity and test coverage are nothing to shy away from.