Let’s say you’re in a management position at prominent European network provider, and you’re trying to assess network quality. Some of your biggest questions are about testing: How quickly are your regression test suites running after network updates? How frequently do your tests uncover bugs, and how do those bugs get resolved? To gain answers to some of these questions, you contact your test team, who send you the most recent test reports—but you can’t make heads or tails of them, and your questions remain unanswered.
Let’s say that after all these years you’re finally ditching your legacy billing system in favor of something new and shiny. For a while now you’ve been hearing about the OSS/BSS solutions of the future, with their unprecedented ability to integrate with IP networks, and you’ve finally decided to take the plunge. When all is said and done, you’ll have transitioned from a system that was basically designed to tally up voice usage and SMS traffic to spit out appropriate bills, to something that offers your customers real-time tracking of their data usage so that they can manage their behavior accordingly. This has the potential to be a huge win, but there’s just one problem: how do you make sure it’s working?
Often, when we talk about quality of service (QoS) we tend to focus on things like latency, jitter, and packet loss, i.e. the network conditions that users experience in their day-to-day mobile device usage. But back-office processes like provisioning and invoicing can often have just as much of an impact on subscriber happiness in the long term—both because subscribers sometimes have to interact with billing systems and because smoother functioning in the back office often helps network operators to improve service elsewhere. For this reason, savvy telco operations tend to think long and hard about storage and access to subscriber information.
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.