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?
On some level, the answer is easy: you test it. But the reality is often a bit more complicated than it seems. For starters, you need to be sure that it’s correctly integrated with your NMS/CRM. Then, you need to ascertain that it’s successfully tracking data usage across a whole host of protocols (HTTP, FTP, SIP, SMTP, etc.) and an increasing number of devices (both iOS and increasingly fragmented Android devices), and then make sure that user interface is successfully reflecting that usage. Not only that, but you have to make sure that all of your subscriber data has been ported over from the old system successfully. This can seem like a Herculean task—and yet, it’s mission critical if you want to maintain subscribers and gain new users to your network.
In the above example, we mostly discussed billing, but the larger category of OSS/BSS functionality can have a tremendous impact on the average telco’s ability to protect revenue and roll out new service offerings. This includes things like billing, yes, but it also includes provisioning, data collection, and monitoring. The OSS/BSS divide breaks down thusly:
- OSS: Supports back-office operations like provisioning, service activation, and bandwidth management. This is the functionality that helps users within the telco operation to design, activate, and assure service for new offerings (e.g. VoIP network connections in a new region, or a new roaming partnership with another operator).
- BSS: Integrates with your CRM to generate invoices, collect bills, process payments, and basically do anything else required for the customer-facing aspects of order fulfillment and billing. Crucially, this needs to power both intra-operational functionality and end-user functionality, meaning that workable UX is a must.
When testers think of the technical challenges that come with verifying service for a telco network’s offerings, these aren’t typically the most pressing items on the agenda, since they don’t address network quality per se. In point of fact, however, their successful implementation can have a big impact on perceived quality of service (QoS). Even if you keep latency, jitter, and packet loss to an absolute minimum for your subscribers, they’ll still feel massively irritated if you bill them the wrong amount, or if they can’t see their balance when they want to. No matter how good the rest of your service is, this has the potential to cost you customers. And it’s not just billing that has an impact. Since your OSS infrastructure hugely impacts your ability to roll out new service offerings, it can be the difference between keeping promises to potential customers or losing their business.
Okay, we’ve seen the ways that OSS/BSS systems can and do impact the average telco operator’s bottom line (even before we even get into the question of increased operational efficiency in the back office as a result of improving these systems). It follows logically that OSS/BSS testing—a crucial element of making sure that these systems actually work the way they’re supposed to—directly impacts telco operators’ bottom lines. Like we alluded to above, however, testing in this area can present certain challenges. Specifically, the shear amount of functionality that even a billing system requires means that test cases quickly pile up and become unmanageable. If you’re adopting some degree of automation, this means that single-use code that can’t be adapted and reused is simply not an option.
By the same token, using simulated or rooted devices to verify end user use cases has the potential to leave service gaps hidden in the subtle differences between real, out-of-the-box devices and their simulated or altered equivalents. One potential tactic for keeping these tests manageable is, of course, to automate—but even in an automated environment testers need to make sure they’re writing their tests from the point of view of the end user—meaning both the internal user at the telco operator (for OSS and BSS) and the subscriber out in the world (for BSS). This will help you give structure to what might otherwise become an unwieldy mass of use cases.
The Power of Revenue Assurance
So far, we’ve talked about the ways that OSS and BSS testing impact your bottom line from the perspective of customer attrition. These factors do impact QoS, which means that can and will have an effect on customer retention. But there’s also another element at play here: revenue assurance, i.e. making sure that you’re actually collecting the subscription fees you think you are. Needless to say, if it turns out that there’s an error in your invoicing system that’s preventing payments from going through, you’ll lose out on a lot of potential revenue—especially if you don’t notice immediately.
Again, effective testing for OSS/BSS proves to be a bulwark against lost revenue. And what does effective testing look like? For starters, it should be fast enough to achieve high test coverage, organized enough that results actually translate into bug fixes, and adaptable enough that you don’t have to reinvent the wheel each time you perform a data migration or deploy a new piece of IT. This is often easier said than done, and it takes the right tools and the right approach to make effective testing a reality.