by Yulia Lomanova | August 11, 2021 7:32 am
Data migration is the process of moving data from one location to another, one format to another, or one application to another. Generally, this is the result of introducing a new system or location for the data. The business driver is usually an application migration or consolidation in which legacy systems are replaced or augmented by new applications that will share the same dataset.
The migrations are often started as companies move from on-premises infrastructure and applications to cloud-based storage and applications to optimize or transform their business. Hence, adequate testing is a high-priority effort to ensure data migration is successful. In this article, we are going to cover the particularities of quality engineering in the data migration process.
In terms of arrangements, data migration involves 3 basic steps: Extract data; Transform data; Load data. The migration itself outlines a 7-phase process:
This may appear to be an overwhelming amount of work, but not all these steps are needed for every migration. Each situation is unique, and each company approaches the task differently.
Given this complexity, precise testing should start well in advance of the actual data being migrated so that it gets the right level of awareness and resources. To ensure that the project gets the attention it needs, focus on the most provocative element of the migration – the fact that the legacy system will be turned off. A solid test strategy design is a must!
Therefore, testing strategy phases of the Migration test to be carried out at the QATestLab can be classified as Pre-Migration Testing; Migration Testing; Post Migration Testing.
This test phase is ignored or not considered in simpler applications. But when complex applications are to be migrated, the Pre-Migration activities are to be performed. These are the actions that are taken up during this phase:
Ideally, the migration activity begins with the data backed up on the tape, so that, at any time, the legacy system can be restored. All the scripts and steps must be documented correctly without any ambiguity.
To note down the actual time taken for migration from the point of start of migration till successful restoration of the system is one of the test cases to be executed and hence the ‘Time taken to migrate the system’ needs to be recorded in the final test report which will be delivered as part of Migration test results and this information will be useful during the production launch. The downtime recorded in the test environment is extrapolated to calculate the approximate downtime in the live system. It is on the legacy system where the Migration activity will be carried out.
During this testing, all the components of the environment will usually be brought down and removed from the network to carry out the Migration activities. Hence it is necessary to note the ‘Downtime’ required for the Migration test. Ideally, it will be the same as that of the Migration time. Generally, Migration activity defined in the ‘Migration Guide’ document includes:
It is advisable for the testers to verify the above in the backend of the system or by conducting white box testing. Once the Migration activity is completed, all the servers are brought up and basic tests related to verification of successful migration will be done, which ensures that all the end to end systems are appropriately connected and all the components are talking to each other, DB is up and running, the front end is communicating with the back end successfully. These tests need to be identified earlier and recorded in the Migration Test Specification document. There are possibilities that the software supports multiple different platforms. In such a case, Migration needs to be verified on each of these platforms separately. Verification of Migration scripts will be a part of the Migration test.
Sometimes an individual migration script is also verified using ‘White box testing’ in a standalone testing environment. Hence, Migration testing will be a combination of both white box and Black box testing. Once this migration-related verification is done and corresponding tests are passed, the team can proceed further with the activity of Post-Migration testing.
Once the application is migrated successfully, Post-Migration testing comes into the picture. Here end-to-end system testing is performed in the testing environment. Testers execute identified test cases, test scenarios, use cases with legacy data as well as a new set of data. In addition to these, there are specific items to be verified in the migrated environments which are listed below:
Since the scope of Post-Migration testing becomes very huge, it is ideal to segregate the important tests that need to be done first to qualify that Migration is successful and then to carry out the remaining later.
It is also advisable to automate the end-to-end functional test cases and other possible test cases so that the testing time can be reduced and the results would be available quickly.
When the application is migrated, it does not mean that the test cases have to be written for the wholly new application. Test cases already designed for the legacy should still hold good for the new application. So, as far as possible use the old test cases and convert the legacy test cases to a new application’s cases wherever required.
If there is any feature change in the new application, then test cases related to the feature should be modified. With adding any new features to the new application, new test cases are to be designed for that particular feature.
When there is any feature drop in the new application, related legacy application’s test cases should not be considered for post-migration execution, and they should be marked as not valid and kept apart.
Test cases designed should always be reliable and consistent in terms of usage. Verification of Critical data should be covered in test cases so that it is not missed while executing.
When the design of the new application is different from that of the legacy (UI), then the UI-related test cases should be modified to adapt to the new design. The decision to either update or write new ones, in this case, can be taken by the tester based on the volume of change that happened.
Hence considering the complexity involved in carrying out data Migration Testing, keeping in mind that a small miss in any aspect of verification during testing will lead to the risk of failure of migration at the production, it is very important to carry out careful and thorough study & analysis of the system before and after migration.
Plan and design the effective migration strategy with robust tools along with skilled and trained testers. As we know that Migration has a huge impact on the quality of the application, a fair amount of effort must be invested by the entire team to verify the entire system in all aspects like functionality, performance, security, usability, availability, reliability, compatibility, etc., which in turn will ensure successful ‘Migration Testing’.
Source URL: https://blog.qatestlab.com/2021/08/11/what-is-data-migration-testing/
Copyright ©2021 QATestLab Blog unless otherwise noted.