Blog

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

6 October 2020,
by Dmitry Tishchenko
4 min read
A clear view of smart team scalability
Get to know how to scale your team sagely and gratify end-user needs and fast-paced tech-market requirements.
Agile
Quality assurance
19 August 2020,
by a1qa
4 min read
Data migration to the cloud: enable robust transition through QA
With cloud computing being a pervasive technology, many companies still face challenges to set well-tuned information transfer. Learn how to avoid possible quality issues and be confident in data safety.
Cloud-based testing
Cybersecurity testing
Migration testing
Performance testing
6 August 2020,
by Elena Yakimova
5 min read
How to arrange fruitful joint work with an outsourcing QA team
The head of the web apps testing department sheds light on how to establish more transparent and effective work on the project cooperating with a remote QA team.
Quality assurance
4 June 2020,
by Vitaly Prus
4 min read
SAFe vs. Scrum, and PI planning essentials
Let's shed some light on the SAFe differences from Scrum that are to be considered by the development and QA teams who have migrated from Scrum.
Agile
Quality assurance
29 April 2020,
by a1qa
4 min read
5 lessons we learned from COVID-19
Here are five key lessons the businesses need to learn during this pandemic to somehow achieve the planned outcomes. 
Quality assurance
17 April 2020,
by a1qa
5 min read
QA-focused retrospective: identifying and solving project problems
The a1qa experts came up to consider an effective approach to identify project bottlenecks and get rid of problems successfully.
Agile
Quality assurance
31 March 2020,
by Dmitry Tishchenko
4 min read
QA outsourcing – the respond to unprecedented global challenge
How can companies meet their business-critical needs without health risks? QA outsourcing is the answer. Get to know why it is the right decision in this time of need.
QA consulting
Quality assurance
10 March 2020,
by a1qa
6 min read
Dedicated team model in QA: all you should know about it
Check on everything you should know about when to apply, how to run and pay for a dedicated team in QA.
Interviews
QA consulting
Quality assurance
12 February 2020,
by a1qa
4 min read
a1qa acquires a prominent position among Top Testing Companies at GoodFirms
In the article by a GoodFirms expert, read about a1qa entering the Top Software Testing Companies List and interesting thoughts from the series of interviews with executives.
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.