Between 2008 and 2014, the number of homes in the United States without a landline telephone rose from 25% to 40%. This is a pretty staggering increase, but it makes sense in the context of the rise of mobile phone usage and the increasing reliability of packet-switched networks like LTE and now 5G. And it’s not just the U.S. that’s seeing the trend away from landline telephones: globally, the number of fixed-line telephone subscriptions has shrunk down to 972 million, which represents a sizable decline from its peak.
The decline of the landline might give testers the impression that it’s not worth their time to prioritize PSTN use cases, but that couldn’t be farther from the truth. Though packet switched networks feature layers of technology and protocols above and beyond what’s happening when you place a trunk call, mobile devices still rely on the PSTN for long-distance transport and calls to or from landline numbers.
Though the average mobile subscriber on the street might tell you that he cares a lot less about POTS functionality than he used to, your network’s ability to interconnect with PSTN elements is still crucial, and needs to be prioritized by testers accordingly.
This remains the only way to ensure system interoperability, backward compatibility, and the resulting broader service coverage.
PSTN vs. VoIP
One of the primary reasons for the decline of analog connections around the world is the recent increase in digital technology for managing teleconferencing and other enterprise use cases. Where once the best option might have been something like ISDN (which is designed to send digital voice, video, and data through PSTN circuits), today a large proportion of businesses are opting for enterprise VoIP solutions instead. This is for any number of reasons, from decreased costs to improved performance.
That said, there are some markets (Germany, for instance), where ISDN was a big hit when it was first introduced, and many businesses see little reason to switch away from their circuit-switched technology.
Thus, even as VoIP continues to gain ground, it’s not the only horse in the race—and it can still require PSTN connections in order to function.
As such, it’s difficult to justify leaving PSTN-related activity out of, say, your core network regression tests, since PSTN-related issues could adversely affect subscribers. At the same time, if you’re testing network functionality by hand, the ever-growing number of complex use cases requiring verification makes it seem like you have to triage use cases and toss out the ones that aren’t the most high profile.
Luckily, settling for low test coverage isn’t your only option: you can also opt for automation.
How PSTN Testing Works
In an automated testing environment, testers can easily run through hundreds of use cases per day with a high degree of confidence in the test results. Since the tests themselves are carried out via tests scripts, they’re not prone to the kinds of deviations and errors that human testers inevitably introduce into the process.
Automation of PSTN / ISDN-related test cases requires specific hardware (PSTN / ISDN cards or modems). Once these are orchestrated within your existing test framework, you can run tests on and with them by using defined keywords in the test case scripting language. This puts you in a position to quickly and easily verify a handful of use cases:
- Call handling: This can include dialing and calling, answering and rejecting calls, caller verification, call status verification and many more.
- DTMF: You can verify whether you’re successfully sending dual-tone multi-frequency (DTMF) signals, as well as verifying that those tones are sending the correct information through the network.
- Circuit switched data: This can help you verify that analog data is being encoded and transmitted correctly end-to-end.
- Call recording: There are a number of potential quality-control scenarios where this might apply, such as automatic network announcements.
Again, in an automated testing environment, it’s easy to break down each of these use cases into individual steps for verification, and then bundle all of the use cases together into test suites that can be run at the drop of a hat. Where previously, you were deciding whether this functionality was high priority enough to be included in your standard suite of regression tests, now the extra test volume barely makes a dent in your overall test time.
How PSTN Automation Impacts Customer Satisfaction
Now that we’ve seen how you might go about automating PSTN-related use cases, let’s dig a little deeper into the impact this kind of automation can have on your customers and their satisfaction rates.
Let’s say you’re selling an enterprise client a VoIP subscription for the entire office. One day, you make a handful of updates to your VoIP network, and it’s up to your testers to make sure that no adverse impacts make their way to the users. If you’re struggling to keep pace with increasing test volumes, you might easy let DTMF testing fall by the wayside, only to find that the most recent network changes impacted that functionality, such that the wrong tones would be sent while dialing a call.
If this slipped past the test bench, you’d most likely find out from subscriber complaints. Of course, you’d then work to resolve the situation as quickly as possible. But it might be too late—some of your users might be ready to take their business elsewhere, especially because to them, this seems like very basic functionality. This would have a direct, adverse impact to your bottom line, not to mention your reputation.
PSTN connections are here to stay, at least for a while. Luckily, in an automated environment, there’s no need to skimp on testing use cases like these. If a network update is going to cause issues for PSTN-related functionality, you’ll be able to identify the problem and make the necessary fixes long before the update reaches your subscribers.