Parallel testing to ensure billing system migration quality

Transformation of the billing solution

The billing system is a vital element in any telecom network. High-quality billing solutions predetermine great customer service and operator’s stellar reputation in the market.

A traditional billing system is network-derived and serves as a tool to calculate fees for services usage (mainly voice and SMS). However, the customers’ needs change and the reality of digital economy press telecom operators to transform their business models and billing solutions.

A redesigned billing solution should have all the features to generate complex offerings and value-added services, operate in real time (as no user wants to exceed their data cap while watching a video), should be agile in terms of services and products.

The transformation process is a long way in terms of development and quality assurance works that should go unnoticed to the customers. To this end, the fees and terms of service provisioning should stay the same as even a slight increase in fees or a calculation mistake will deteriorate customer experience and increase the claims.

Telecom data migration testing

Ensuring high quality of telco software is the key area of the a1qa expertise.

When testing data migration to the new solution, our company applies a combination of testing types. Yet, the final one is Parallel Testing (also called Back-to-back Testing).

The following article provides insights into what we believe needs to be considered and actioned as part of the planning and execution of a successful Parallel Testing for the Telecom industry.

What is Parallel Testing?

From the view of Telecom industry, Parallel Testing is a strategy to verify the quality of data migration from the existing system to the target one. Testing is performed on the same data with both systems running side by side. The results are compared and any mismatches are analyzed.

It is expected, that in the end, any transaction on the migrated clients will have the same effect when performed in the legacy (old) system and a target (new) one.

In our context, the effect is the same fees charged for the usage of the same services, equal calculation and payments reflection on the customer’s balance sheet.

Any discovered discrepancy is a potential defect in software configuration, migration process, or functionality.

What business processes are tested?

Parallel Testing verifies that the following critical business systems processing large scope of the migrated data work as expected:

• Cash payments processing
• Online and offline calls processing
• Balance forwarding, payments, and fee adjustments processing
• Fee calculation
• One-time charges calculation
• Change of the data plan
• Service enabling/disabling
• Data packets activating/deactivating
• SIM card replacement
• Billing
• Remuneration calculation

Setting up environment for Parallel Testing

Setting up a right test environment will ensure testing success. The following components are required for Parallel Testing:

• A testbed with a target system
• An environment for data comparison and analysis

The data for the legacy system are collected from the production environment.

Before testing starts, at least one billing plan with all its products should be located on the testbed. Mapping tables with all products, customers’ attributes should be developed.

On the testbed of the target system, there should be a stable version of the latest release that has passed system and acceptance testing.

Additional test environment will help to accomplish the following tasks:

• Copy operating results of the business processes under test (fees, payments, bonuses, accounts, post-migration data records, etc.)
• Launch scripts for comparison and save results
• Analyze discrepancies with the help of the supporting subject tables

Two phases of Parallel Testing

Parallel Testing is performed in two phases:

• Preliminary phase
• Regular phase

In the preliminary phase, various kinds of defects are detected and eliminated: poor product mapping, incomplete clients’ attributes transfer, poor synchronization of data between billing subsystems, functionality flaws.

Scripts for results comparison and data analysis will also be debugged in this stage.

Finally, the testing team should get ready for discrepancies analysis before launching regular tests.

Once the preliminary round of testing is over, the regular phase begins.

The main goal of the regular testing round is to detect and eliminate the defects mentioned above.

The difference between the two rounds lies with the amount of clients’ data under test. In the preliminary round, engineers will take only a small portion of the clients that are to be migrated. In the regular phase, all clients should be taken.

By the way, in some cases, it’s possible to omit the preliminary phase.

Dry run testing phase

In any of the phases (preliminary and regular), Parallel Testing is performed immediately after the iteration of Dry Run.

Dry Run shall provide the scope of clients that can migrate to a new system.

For example, the project requirements may define that the clients with a debt in the balance sheet can’t migrate until the debt is paid off.

So in fact, Dry Run is the preparation of data for Parallel Testing.

Once the testing is over, all discrepancies are analyzed and the reasons for them are examined. If necessary, defects are reported to the bug tracking system.

After that, the discrepancy statistics correlated to business processes in collected. The discrepancies impact on the overall workflow is estimated and described.

All the results are presented in the final report.

All the defects that have been detected in the previous stages of Parallel Testing are validated while executing system test cases. However, their elimination should be confirmed in the next stage of Parallel Testing for the same scope of data and products.

Summing up

Parallel Testing is an extra type of data migration testing. Due to the relatively high cost, we recommend launching parallel tests once the system testing that will detect the majority of defects is over.

The advantage of Parallel Testing is that this type of testing provides a wide coverage of both the subscriber base and the configuration of the company’s products due to the fact that real data are taken from the production environment and processed in mass.

In addition, Parallel Testing detects defects that were overseen during system testing and brings down financial and reputational risks of data migration to a minimum.

Finally, we’d like to note down that this type of testing can be useful not only for telecom solutions but also for testing migration of large scope of data of any type.

Contact us to get more information on how our services can help your software deliver the expected value to your business.