Parallel testing to ensure billing system migration quality

What needs to be considered and actioned as part of the planning and execution of a successful Parallel Testing for the Telecom industry.
7 March 2018
Migration testing
Quality assurance
Web app testing
The article by Julia Ilyushenkova
Head of Telco and Web applications testing department

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.

More Posts

17 April 2023,
by a1qa
4 min read
Why do bugs get missed? Learn the problems and tips to avoid them
Still, finding overlooked bugs after the app goes live? Let’s find out why this happens and how to fix it.
Quality assurance
Test automation
31 January 2023,
by a1qa
5 min read
Best of 2022 by executives: 8 most visited a1qa blog posts
Let’s look back and revisit the most visited a1qa articles of 2022!
Quality assurance
Test automation
12 January 2023,
by a1qa
4 min read
The future of software testing: top 4 impactful trends that will dominate in 2023
Consider the major industry trends for the upcoming year to know how to improve current QA strategies and stay ahead of the curve.
QA trends
Quality assurance
Test automation
7 December 2022,
by Dileep Marway
3 min read
Release at pace with test automation: What, why, and how to measure success?
An automation-first approach is key to enhancing testing capabilities and increasing overall operational efficiency. However, I would suggest justifying its implementation, so that it can deliver the promised value.
Quality assurance
Test automation
2 December 2022,
by Dileep Marway
3 min read
What is a сulture of happiness for a QA company?
Great culture drives employee engagement and satisfaction, contributes to an impressive work output, and improves organisational performance. But how do we build a culture of happiness? In this blog, I will share more on the answer to this.
Quality assurance
30 November 2022,
by Dileep Marway
3 min read
Agile QA – what is needed for greater flexibility and speed?
What should your QA team focus on to become truly agile, enable quality at speed, and contribute to lasting performance improvement? In addition to introducing test automation, I suggest considering shared responsibility for software soundness.
Quality assurance
28 November 2022,
by a1qa
9 min read
Interview with Dileep Marway on a series of articles “Agility and speed: Supercharging your business strategies with QA”
We cooperated with the VP of Engineering and Quality at SHL to present you with a series of his blog posts on: culture of happiness, test automation, and Agile-driven QA. Happy reading!
Quality assurance
Software lifecycle QA
Test automation
31 October 2022,
by a1qa
4 min read
Optimizing telecom budgets with QA outsourcing: everything you need to know. Part 2 
Welcome to Part 2 of our blog on QA outsourcing and optimizing telecom budget with it. Let’s delve deeper into the topic!
QA trends
Quality assurance
27 October 2022,
by a1qa
4 min read
Optimizing telecom budgets with QA outsourcing: everything you need to know. Part 1
Learn how to optimize telecom’s quality assurance expenses by relying on a trusted QA partner.
QA trends
Quality assurance

Get in touch

Please fill in the required field.
Email address seems invalid.
Please fill in the required field.
We use cookies on our website to improve its functionality and to enhance your user experience. We also use cookies for analytics. If you continue to browse this website, we will assume you agree that we can place cookies on your device. For more details, please read our Privacy and Cookies Policy.