5 Ways Telecoms Can Increase Test Velocity

Let’s say you’re migrating all of your subscribers to a highly redundant HSS database. You know it’s going to be a long process, but you want to set an ambitious deadline and perform the migration before your next quarterly all-hands meeting.

As such, you put together a list of the things that are most likely to cause delays. And what should be at the top of that list? Depending on how your current test operations function, service verification could be your prime suspect.

As telco networks get more and more complex—with the introduction of new technology like 5G, IoT devices, increasingly stringent requirements for legacy interworking, and ever-rising customer expectations—testing has a greater potential to be a significant bottleneck as network operators try to bring new services to market or update their internal systems.

This all raises the question: how can telco operators increase test velocity in order to make sure that this doesn’t happen? We’re glad you asked…

1. Consider Keyword-based Tests

In SEGRON’s experience, the number of test cases that a typical telco tester can work through in a day has been dropping in recent years, from around 10 several years ago to around six today. Since resources are spread thinner than ever before, anything you can do to make the testing process more open and less siloized has the potential to reduce bottlenecks.

This is where keyword-based testing can make a big impact. Keyword-based tests essentially provide testers with a highly-readable test scripting language based on pre-defined keywords, meaning that executing tests is just a matter of plugging in the appropriate keywords and running the scripts. From a test velocity standpoint, this has three big advantages:

• Readable test scripts mean that less technical personnel can easily run tests; this widens the pool of resources that testing teams can leverage to power through test cases.
• Keyword-based test results are easier to read, meaning that testers can find root causes much more quickly.
• Tests can be reused quickly and easily by swapping out keywords, meaning that after the initial scripting effort you can radically reduce the time typically associated with crafting new tests.

2. Mind Your Reporting

This strategy is obviously related to the one above, considering that keyword-based testing touts its readability as one of its primary virtues. That said, the question of test documentation does go deeper than that. You first have to make sure your test results are readable, but beyond that you also need to make sure that they’re stored in such a way that people can access them easily.

If your keyword-based test results are stuck within a silo somewhere, there’s not very much they can do to speed up service verification. By the same token, the test scripts themselves need to be made accessible for those who might need them.

To this end, a comprehensive test automation framework can provide a lot of value via an intuitive interface that helps you keep track of your documentation.

In this way, you can become more operationally efficient in addition to being more technologically efficient, i.e. you lay the foundations to make sure that everyone knows who should do what, when.

3. Avoid Rooted Devices

This might seem like something of a niche suggestion, but when you get down the last bullet point (“Choose the Right Tools”), it may make a little more sense.

Because Android and iOS mobile devices aren’t designed to let you install testing applications, many test automation providers will use phones that have been rooted or jailbreaked—i.e. hacked to allow users to modify the Android OS or install unauthorized iPhone applications, respectively.

This might seem like a potential time saver (automation generally is), but in point of fact this kind of workflow can create more work for testers in the long run. Why? Because these devices, once they’ve been rooted, are no longer accurate representations of the devices that subscribers will actually utilize.

Not only is the OS subtly different, it also won’t receive updates from the manufacturer, meaning that tests performed on rooted devices will be less accurate than the same tests performed on out-of-the-box devices. With reduced accuracy comes slow bug fixes and increased retesting needs.

4. Decrease Total Testing Time

This one might seem somewhat obvious, but it’s crucial to remember that the velocity of any given testing flow is only part of the story. If you run through a set of conformance tests in record time, for instance, but errors in test execution create a need for lengthier regression tests later, you haven’t necessarily saved time.

Obviously, each new service launch or network update is a balancing act between verifying as much as possible up front and living with the attendant aftercare, but the more effectively you’re able to frontload testing the more you can reduce time spent on future tests.

That’s why we think it’s often wise to consider total test time as KPI in addition to test velocity—and then shuffle around your operational resources accordingly.

5. Choose the Right Tools

Almost all of what we’ve suggested above lends itself well to or relies upon automation, which means that the success in large part a function of choosing the right tools for the job. Easier said than done, obviously.

But if you are evaluating testing tools based on their ability to improve your test velocity (or any other metric of your choice), there are some considerations you need to make:

• Does the test framework offer tests on out-of-the-box devices?
• How easy or difficult is it to script use cases?
• What technology is it powered by?
• Is it specific to the telco domain? (This might mean, for instance, that it has built-in test libraries for things like PTSN verification, equipment conformance tests, etc., with the potential to decrease test set-up time.)
• How easily does it integrate with your existing verification workflows?
• Is it future-proof?

By examining any potential testing technology deployments through this lens, you can make sure that the vendor or service provider’s offering align with your actual testing needs. In the long run, this can have a huge impact on how quickly—and accurately—you verify service on your network.