Way back in the day, if you were on the go and needed to make a phone call, you kept your eyes peeled for the nearest payphone. You would drop in your coins and the operator would connect you to your desired call recipient. After the time you paid for had run out, a live operator would butt in and let you know that in order to extend your call you needed to add more money. Today, the idea of something like this happening during a VoLTE call seems a little bit absurd—but in point of fact it represents a need that all telco operators still grapple with: real-time provisioning of services based on what the user has actually paid for.
Let’s say you have a small system whose functionality you want to test, and you determine that there are five distinct use cases that require verification. As a technically-adept test engineer with a fair amount of programming skill, what do you do? In all likelihood, you simply script up each test case individually, so that for each use case there’s a unique piece of code that needs to run in order to make sure that everything is working smoothly. This makes sense, and as test automation has become more common (in some sectors, anyway), we've seen a lot more people doing just that. For a limited number of test cases, this is probably the smart thing to do. But what happens when it’s not half a dozen use cases that require scripting, but hundreds or thousands?
Lots of articles have argued that the first ever internet of things (IoT) device was a soda machine at Carnegie Mellon that was connected to the early internet in the 1980s. The machine was famously automated to let users on the local network see how recently the machine had been filled (and thus how cold the soda was). It’s a great story—but one device does not an internet make. In other words, what we in the modern era understand as the IoT isn’t really about individual devices; it’s about a tremendous volume of different devices all working together in tandem.
Sometimes, the OS that comes built into an Apple or Android device can seem like it’s actively preventing you from doing what you want. And, to some extent, that’s true—Apple only lets you download the apps that are in the App Store because there are some actions that they want to prevent you from taking. As an end user, this often seems capricious and arbitrary. As a tester, it feels similar: why shouldn’t you be allowed to make the necessary changes and additions to the phone’s functionality to make end-to-end testing easier?
In the US right now, Verizon and T-Mobile are battling it out for who can provide the most extensive LTE coverage. And as of OpenSignal’s 2018 report, the two were in a statistical tie—each was able to provide an LTE signal 93.7% of the time. These are historic highs for the companies, and objectively impressive numbers, but that still means that they’re failing to provide an LTE signal fully one-twentieth of the time. As such, SRVCC (Single Radio Voice Call Continuity) would still be critical to providing high quality of service (QoS). Why? Because right now it’s the standard solution for ensuring mid-call handovers from all-IP LTE networks to circuit-switched call bearer 2G/3G networks.
If you’re a telco test engineer, you know that the world of telecommunications is getting more complex by the day. Your service needs to integrate with more devices than ever, and you still have to maintain interworking with any number of legacy systems. This is driving an increase in the number of test cases that require verification, and also a renewed push towards automation across the field. Whether you’re selecting an automation solution or simply trying to keep your testing process as efficient as possible, it’s important to keep tabs on the new challenges and opportunities that are likely to be coming down the pike.
Back in 2017, the UK launched its 5G Testbeds and Trials Programme, the stated aim of which was to support coordinated research into 5G technology and use cases among British telecom businesses, equipment manufacturers, and scientists. By their account, the creation of these 5G testbeds provides a crucial proving ground for technology that’s still taking shape, and whose full uses haven’t come close to being explored yet. The UK envisions a world in which 5G powers increased connectivity in rural areas, on roads, and along rail lines, as well as smart tourism and smart cities and towns, but they won’t know whether these goals are realistic until they’ve had the chance to test things out in a safe environment.
Backward compatibility is a noble goal for any communication system. For telecom networks in particular, it's an important part of providing seamless coverage across legacy platforms, which means you can keep customers happy without forcing them to upgrade their service constantly. By placing an emphasis on service in this way, you can help protect revenue over time. That said, ensuring legacy integration can often provide challenges for operators.
One of the most significant ways in which the rise of mobile phones and laptops has changed the business world is encouraging a tremendous increase in mobility. Not only are employees at many businesses able to telecommute more easily than ever before, folks traveling for business are able to stay connected so effectively that it can feel like they’ve never left the office at all. For obvious reasons, this makes life easier and more pleasant for a lot of folks, all while helping to make truly global enterprises more connected than ever. The cost of this increased freedom, however, is a subsequent increase in complexity for telco operators.
When it comes to banking and financial services functionality, “almost” doesn’t count. From your end users’ perspective, they’re either able to complete their desired action—whether that’s checking their balance, transferring funds, or setting up automatic payments—or they’re not. They’re not going to spend a lot of time looking for workarounds, they’re simply going to register their displeasure by choosing a new app or a new service provider.