The modern cycle of updates for telecom networks continues to speed up, and telco operators need to do the same in order to keep pace with the market. For some of you, this may be leading you to consider test automation for verifying service on your network.
Sure, there’s plenty of content out there about automated testing, and some of if even pertains to the specific challenges that your company has—but it’s still more than a little bit daunting.
You know you need a framework that can automatically test, for instance, audio quality for VoLTE service across a suite of modern and legacy devices, but how do you get started?
We’re here to help with exactly that question. Of course, nothing as complex as modern telecommunications testing can really be broken down into 3 steps, so there will be some fill-in-the-gaps along the way, but here we’re presenting a checklist that should help you get started with a clear plan of action for automating your network tests.
If you can check off every step on this list, you can almost certainly increase your testing throughput, save your fellow engineers a boatload of time, and increase your ROI in the process.
Get Buy-in from Stakeholders
We’re certainly not the first ones to suggest this, but when the implementation of a testing framework goes wrong the problem is often not the technology itself—usually it’s a case of miscommunication and mismanaged expectations within the organization that’s adopting the testing solution.
If your CIO expects one thing and your direct manager expects another, there’s a good chance that even a technically “successful” set of tests will be deemed a failure because it can’t meet two conflicting sets of expectations.
By the same token, if there isn’t a clear plan in place for who writes which test cases, how the results are analyzed and addressed, which areas are being tested on what timeframe, etc., there’s going to be time-consuming and value-draining confusion.
The antidote to this kind of confusion and operational disconnect is to seek out buy-in from your key stakeholders and set clear expectations for who’s doing what, when, and what your expectations are for your testers, engineers, and vendors.
The scope of this task will, of course, scale with the size of your deployment. If, for starters, you’re just deploying an automation solution within one particular area of your test lab, your first hurdle is to get the specific affected team members on board. Everyone should know:
- What the expectations are for each role
- What your projected timeline is
- Who’s taking ownership of what steps
Likewise, you should make sure that you’re all keyed into a common narrative about your goals. Are you specifically trying to increase test coverage? Improve reporting quality? Test drive a solution for potential wider adoption?
Whatever it is, be clear and explicit. Then, if you decide to strive for wider adoption within the organization, you can widen the circle of stakeholders and build on the work you’ve already done.
Design Your Test Cases
Okay, you’ve got the relevant people within your operation in the right mindset to approach automating your network tests. What happens next? Well, to simplify and streamline for the sake of giving you a handy checklist, it’s time to define the use cases you’ll be testing.
If, like we discussed above, you’re working on VoLTE quality verification for legacy devices, you’ll need to outline which devices and which user actions you’re testing.
For most automated testing solutions, you’ll be presented with a scripting language that helps you define these use cases in detail. You may also have the option of using pre-configured use cases that don’t require any additional coding on your end.
Because the proliferation of new devices, standards, and protocols in the telco domain is leading to a jump in the number of use cases that require verification in a typical test, your ability to easily define those use cases within your test framework is increasingly crucial.
As such, this step is a critical one to think through when you’re at the vendor selection stage. Well before any sort of deployment, you should make sure that coding up use cases isn’t going to become a huge time suck—either because of a lack of built-in use cases or a byzantine scripting language. Ultimately, these use cases will form the foundations of your testing automation flow.
Rinse and Repeat
Okay, steps one and two hopefully gave you a quick and dirty version of how to get started on a process that can often seem mysterious or confusing. This final step, however, is less about get started and more about making sure that you maximize your automaton ROI.
Once you’ve set expectations, established your test cases, and actually tested your next deployment of network updates, it’s time to do the whole thing over again. Why? Because testing is most valuable when it’s done consistently and continuously.
No doubt you’ll be preparing a new update soon, and with any luck you can improve upon the first tests and iron out any kinks that may have arisen in the first go around. Even if you’re not actively ready to verify your next update, continuous regression testing is a crucial piece of the network quality puzzle—one that really only becomes feasible in environments that boast a certain degree of automation.
As with the step above, this is an important step to consider at the vendor selection phase: how scalable is the service you’re considering? How easy is to repeat your tests after the first go around? How effectively can users translate results into actual insights into bugs and areas of improvement in your network?
If your vendor provides satisfactory answers to these questions, they put you in a position to perform your automated tests in a repeatable, ongoing way. This might not sound like much, but it’s an important step towards creating a culture of testing within your organization.
That culture of testing can, in turn, go a long way towards the long-term health of your network by increasing baseline test coverage and, thus, service quality.
