Checkout our demo site to practice selenium https://magento.softwaretestingboard.com/

0 like 0 dislike
373 views
by Contributing Tester (74 points)
retagged by
What is Migration Testing? Can you define types of Migration Testing?

2 Answers

1 like 0 dislike
by Master (1.2k points)
edited by

There are a few Types of Migration Testing is fundamental to move data from the Legacy framework to the new framework with no data loss.

What is Migration Testing?

Migration Testing Definition:

Migration testing in software testing is a verification procedure of relocation of the inheritance framework to the new framework with negligible interruption/downtime, with data respectability and no loss of data, while guaranteeing that all the predefined non-functional and functional parts of the application met post-migration.

Types of Migration Testing:

The accompanying is the distinctive types of software migration testing that regularly happen frequently:

  • Database Migration
  • Server Migration
  • Operating System Migration
  • Application Migration

Database Migration testing:

Database Migration testing approach is moving applications, cron employments, all data exchange and components from inheritance database software framework to another new database software framework. Here database software framework in the sense Data warehouse, Hadoop or whatever other structures which can deal with the current functionality and handle the information with no execution issues.

A lot of database testing will be included particularly in data migration testing scenarios. Here are the assortments of data migration contextual analyses such as Migration of Operational Data Store to Pentaho, Migration of DW to Hadoop or some other ETL tool and so forth. Any of the information relocation or supplanting ETL data migration testing tools with another ETL tools we should have the parallel framework all the while, so the data comparison should be entirely some accommodating procedure.

Data migration testing strategy:

  • Guarantee whether the mappings at field and table levels don’t change.
  • Guaranteeing if data moved entirely and precisely.
  • Guarantee if the inheritance database not updated during tests after migration.
  • Post-migration and Pre-migration testing exercises.

Server Migration:

Server Migration is essentially the demonstration of moving your server data and configuration starting with one server then onto the next. In some cases, this migration is starting from one server platform to another, for example, from a 1and1 Virtual Server to a 1and1 Cloud Server.

Commonly, the demonstration of moving your server done manually. This is mostly due to there is no real way to automate the migration testing approach of one server stage to another. In addition to the majority of our servers accompany root or overseer get, enabling you to have full control over the setup and design of the server. This outcome in a more noteworthy potential for inconveniences to emerge during any one-measure fits-all automated migration testing strategy.

Testing actions here will be:

  • Testing consistency with the new server.
  • Guarantee catalog names, document sharing and so forth. Stay unaltered or change manually according to the configurations.
  • Guaranteeing no changes in the new server or data corruption.
  • Testing information is taking care of in the new server.

Operating System Migration:

Operating System Migration is a software migration testing types where an application is migrated starting with one OS then onto the next. This includes a lot of difficulties as the base stage itself changed, and there is an immense danger of compatibility. Indeed, even system, arrangements, interfaces, and significantly more segments require re-outlining.

Cases of OS Migration:

  • Relocating to Cloud-based Software as a Server.
  • Relocating to Cloud-based VMs and so on.
  • Relocation from Windows to Linux
  • Relocation from Windows to MAC

Testing actions here will be:

  • Examining the conditions in the new OS.
  • Flows in App may fluctuate when contrasted with the inheritance OS. Consequently, Extensive testing is needed
  • Extensive compatibility testing with every single conceivable combination in the new OS
  • Understanding and testing the application as changes in design impacts the application relying upon its kind.

Application Migration:

Application migration is the way toward moving an application program starting with one condition then onto the next. Cases incorporate movement from an on-premises undertaking server to a cloud supplier’s condition or starting with one cloud condition then onto the next.

Testing Actions here will be:

  • Examine and test every one of the streams in inheritance application against the new app.
  • Examining necessities and recognizing the steady prerequisites.
  • Examining the extent of testing.
  • Test the new streams in the relocated application assuming any.

Subsequently recognizing what Types of Migration Testing are going on and what are the particular viewpoints to be tested relying on the Type of Migration, will guarantee all the conceivable bottlenecks that may happen.

Either post migration or migration can be distinguished well ahead of time while Testing in the Lab and can be alleviated by settling them guaranteeing efficient ‘Movement.

1 like 0 dislike
by Expert (748 points)

data-migration-1

Database migration testing is needed when you move data from the old database(s) to a new database. The old database is called the legacy database or the source database and the new database is called the target database or the destination database. Database migration may be done manually but it is more common to use an automated ETL (Extract-Transform-Load) process to move the data. In addition to mapping the old data structure to the new one, the ETL tool may incorporate certain business-rules to increase the quality of data moved to the target database.

Now, the question arises regarding the scope of your database migration testing. Here are the things that you may want to test.
1. All the live (not expired) entities e.g. customer records, order records are loaded into the target database. Each entity should be loaded just once i.e. there should not be a duplication of entities.
2. Every attribute (present in the source database) of every entity (present in the source database) is loaded into the target database.
3. All data related to a particular entity is loaded in each relevant table in the target database.
4. Each required business rule is implemented correctly in the ETL tool.
5. The data migration process performs reasonably fast and without any major bottleneck.

Next, let us see the challenges that you may face in database migration testing.
1. The data in the source database(s) changes during the test.
2. Some source data is corrupt.
3. The mappings between the tables/ fields of the source databases(s) and target database are changed by the database development/ migration team.
4. A part of the data is rejected by the target database.
5. Due to the slow database migration process or the large size of the source data, it takes a long time for the data to be migrated.

The test approach for database migration testing consists of the following activities:

I. Design the validation tests
In order to test database migration, you need to use SQL queries (created either by hand or using a tool e.g. a query creator). You need to create the validation queries to run against both the source as well as the target databases. Your validation queries should cover the scope defined by you. It is common to arrange the validation queries in a hierarchy e.g. you want to test if all the Orders records have migrated before you test for all OrderDetails records. Put logging statements within your queries for the purpose of effective analysis and bug reporting later.

II. Set up the test environment
The test environment should contain a copy of the source database, the ETL tool (if applicable) and a clean copy of the target database. You should isolate the test environment so that it does not change externally.

III. Run your validation tests
Depending on your test design, you need not wait for the database migration process to finish before you start your tests.


IV. Report the bugs
You should report the following data for each failed test:
    a. Name of the entity that failed the test
    b. Number of rows or columns that failed the test
    c. If applicable, the database error details (error number and error description)
    d. Validation query

    d. User account under which you run your validation test
    e. Date and time the test was run

Keep the tips below in mind to refine your test approach:

1. You should take a backup of the current copies of the source and target databases. This would help you in case you need to re-start your test. This would also help you in reproducing any bugs.
2. If some source data is corrupt (e.g. unreadable or incomplete), you should find out if the ETL tool takes any action on such data. If so, your validation tests should confirm these actions. The ETL tool should not simply accept the corrupt data as such.
3. If the mappings between the tables/ fields of the source and target databases are changed frequently, you should first test the stable mappings.
4. In order to find out the point of failure quickly, you should create modular validation tests. If your tests are modular, it may be possible for you to execute some of your tests before the data migration process finishes. Running some tests while the data migration process is still running would save you time.
5. If the database migration process is manual, you have to run your validation queries externally. However, if the process uses an ETL tool, you have the choice to integrate your validation queries within the ETL tool.


This site is for software testing professionals, where you can ask all your questions and get answers from 1300+ masters of the profession. Click here to submit yours now!

...