The need for rapid digital transformation and new, more complex product offerings, combined with the burden of regulatory compliance, are pushing traditional telecom OSS/BSS implementation partners to transform the way they operate.
This journey is critical and requires a detailed approach towards overall simplification, aimed at improving infrastructure and integration with third-party systems, data and process consolidation, convergence of business lines and new service enablement, says Ravindra Wickramaarachchi, QA Manager, Virtusa
While the IT side of the business makes rapid progress, meeting cost compression and faster delivery cycle objectives calls for an understanding of how the transformation journey is being tested. This isn’t achievable without a close examination of OSS/BSS test strategies.
The OSS/BSS landscape:
So what does the OSS/BSS landscape look like? At the bare minimum, the key components of any OSS/BSS system include the following:
- Integration with a CRM system for content management, order management, customer loyalty and retention management, and call centre or IVRS activity
- Provisioning and service fulfillment for service activation, network inventory and workforce management
- Retail billing systems for rating and collection
- Systems for data collection, mediation, fraud management and interconnected billing – also known as wholesale billing
- A network monitoring system for identifying and resolving any network problems
Developing the right test strategy: Be BOLD –
Apply ‘Business Objectives Led Design’ (BOLD)
As ever, it’s important to understand the key business benefits before embarking on the OSS/BSS transformation process. Start by looking at the key business objectives and ensure that your test design incorporates scenarios which align with them. For example, measuring the quality of service, the effectiveness of billing, invoicing and payment systems and enhancing customer experience are all potential targets to work towards. It’s also worth considering production data and historical trends to identify potential product failures in the market, making ‘fitness for use’ the mantra, rather than simple validation.
Optimise – Apply test optimisation techniques to achieve your coverage while reducing test cases
Transaction processing, which requires the integration of different systems and components, relies on pre-defined workflows and business rules. Generally, test teams weighing options of exhaustive testing (testing all combinations) against time sensitivity may consider the latter option, only to find defects slipping into production. Applying test optimisation through scientifically defined algorithms will help teams achieve right the coverage without having to boil the ocean. It’s always recommended that the test strategy should look for test case optimisation where ever possible.
Time Travel – Is it possible in testing?
Certain end-to-end (E2E) test scenarios are known to be thoroughly time consuming. These processes include data aggregation from different systems to determine the value of the service itself. Similarly, bill Generation is based on product plans, tracking receivables in order to wait for payment till the due date and ’Dunning’, when payment is outstanding beyond the due date. Typically, E2E testing of these scenarios can take as much as a month, as providers tend to dispatch bills up to two weeks prior to the due date and each phase in the dunning process usually gets triggered in pre-defined intervals.
However, most firms won’t have the resources to wait for this amount of time, so your strategy should include a ‘time travel’ mechanism to mimic future dates. This should be carefully planned to ensure that data covering different combinations of outcomes is accounted for. Conversely, tests that don’t require this method should be avoided when applying ‘time travel’ mechanisms to guard against erratic behavior. This highlights the importance of looking at the impact of external systems when the date and time have been modified, and when strategy has been updated to reflect this.
Other important factors
However, the testing process doesn’t end there. Designing the right environment, designing the data (taking several plans and pricing options into account), and defining the right organisational model are all important factors to consider.
Finally, it’s equally important to look at test asset reusability, including the usage of pre-defined test scenarios, test cases and test data. This can significantly reduce the test design time while almost guaranteeing better test coverage.
Ultimately, testing OSS/BSS transformation requires a more sophisticated approach than the traditional model. While domain understanding can translate into high quality and reusable test assets, the testing team should focus on designing tests that measure the impact on customer experience. Plus, the optimisation of tests through impact based testing, ’time travel’ tests and designing the right test environment are vital parts of the process. Teams should also focus on this process early in the life cycle to identify potential defects as soon as they appear, helping to improve code quality through static analysis tools and reliance on lean test automation.
The author of this blog is Ravindra Wickramaarachchi, QA Manager, Virtusa
