As recently as a few years ago, the idea of a smart home—in which all of your appliances and other sensors around your home are networked together digitally—still seemed more like science fiction than a fact of life. And yet, today you can walk into many new homes and use your smartphone to control the temperature and the lighting, you can preheat the oven remotely, and you can get alerts to your mobile device if your smoke detector or burglar alarm goes off. It’s the type of home that technologists have dreamed of for decades.
What makes the modern smart home possible is the IoT, or internet of things. By turns, what makes the internet of things possible is the increasing speed and reliability of telecommunications networks. Especially with the slow rollout of 5G driving a decrease in latency times across the board, we expect to see this technology become more and more prevalent while covering more use cases than ever before. Given that fact, IoT device testing is going to become mission critical for telco operators in a way that it hasn’t been in the past. Here are a few tips for managing this shift in priorities effectively.
1. Prioritize Emergency Use Cases
For most devices that connect to telecom networks, the occasional gap in service isn’t going to lead to catastrophe—in part because things like jitter-free video calling are rarely life-and-death, and in part because potentially problematic gaps are easy to notice when a device is in active use. For IoT devices, on the other hand, even critical outages are sometimes harder to spot, because most of the time the devices in question won’t be sending out alerts anyway. This opens up users to potentially disastrous scenarios. In the case of a car crash, for instance, discovering that your sensors have been kicked off their network and won’t be able to send out an automated emergency call is simply not an option. For this reason, when testers in this area are sketching out and prioritizing the use cases that require testing, emergency use cases need to be moved to the top of the list, with target levels of test coverage and accuracy as high as possible.
2. Focus on Load Testing
While focusing on emergency use cases will help testers to respond to the difference in customer expectations that comes along with these devices, load testing can help you to manage the fundamentally different ways in which these types of devices will interact with your network. In a typical smart factory, for instance, you might find dozens or hundreds of different sensors all working in tandem to send data back to a primary control tower. In cases like these, it’s not enough to verify different functionality on an individual basis, you also need to be sure that you don’t experience any slowdowns when the devices are all firing at once. After all, if your users find that they can’t scale up their IoT usage as needed, they’ll likely seek out a new network on which to run them.
3. Test Over-the-air
Though we haven’t spoken about it too much up till this point, one of the most important developments for the future of IoT will almost certainly be the adoption of 5G networks around the world. Why? Because sub millisecond latency times will finally empower users to rely on ultra-high speed wireless connectivity for real-time monitoring. Where, previously, long latency times made complex systems of wireless devices difficult to optimize, 5G will make wireless network connectivity the most attractive option for a host of new devices. This has an impact on network loads, obviously, but it should also have an impact on the way that you physically conduct your tests. Specifically, it should spur you to conduct over-the-air tests in order to make absolutely certain that your latency times are within the (miniscule) acceptable levels. In doing so, you can more closely recreate the conditions under which end users will actually deploy these devices, thereby erasing some of the inherent difference between test lab and field settings.
4. Perform Continuous Regression Tests
Okay, we admit that this advice could be applied to almost any variety of telecom testing you care to tackle. But it’s particularly crucial for IoT devices because they have so many moving parts, so to speak. Typically, an IoT device will involve a number of layers:
Each of these layers will have to integrate successfully with the others, meaning that for any given update to any layer of technology you have to be sure that the interplay between the layers hasn’t been affected. What this means in practical fact is that a tester's job is never done, especially when it comes to devices that have short update cycles and potentially very little day-to-day direct user interaction. Like we saw above with emergency functionality, it’s your job as a tester to identify potential gaps in service before your customers do—even in a technological landscape that changes rapidly.
Now, all of the advice we’ve doled out above might seem daunting—and with good reason. Given the increasing complexity of telco networks (which is itself driven in large part by these very devices), the number of use cases that your average tester can verify in a given day is decreasing steadily. This means that even as you work to prioritize emergency use cases, for instance, you still might not be able to reach high levels of test coverage with manual testing. At the same time, the number of use cases requiring service verification increases as the device market continues to fragment. For this reason, our position is that the only way to meet the looming challenges presented by the IoT is to automate your test frameworks. If you can perform automated tests on out-of-the-box IoT devices, you can suddenly run through hundreds of use cases per day, meaning that you’ll finally be in a practical position to actually take the advice above. As a result, you’ll keep your network quality high for IoT users, and you'll retain those customers more easily in the future.
LEARN MORE ABOUT TEST AUTOMATION
Are you looking for a solution to automate your service verification that includes both true end-to-end testing and full access to the systems under test.