查看: 1551|回复: 14

Data Migration Testing Tutorial: A Complete Guide

[复制链接]
认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2018-11-28 15:59 | 显示全部楼层 |阅读模式
Overview of Data Migration Testing:
It is quite often heard that an application is moved to a different server, the technology is changed, it is updated to the next version or moved to different database server etc.,
  • What does this actually mean?
  • What is expected from the testing team in these situations?

From the testing point of view, it all means that the application has to be tested thoroughly end-to-end along with migration from the existing system to the new system successfully.
Tutorials in this series:
System testing has to be performed in this case with all the data, which are used in an old application and the new data as well. Existing functionality needs to be verified along with the new/modified functionality.

Instead of just Migration Testing, it can also be termed as Data Migration Testing, where the entire data of the user will be migrated to a new system.
So, Migration testing includes testing with old data, new data or combination of the both, old features (unchanged features), and the new features.
Old application is usually termed as ‘legacy’ application. Along with new/upgraded application, it is also mandatory to keep testing legacy application until the new/upgraded ones become stable and consistent. Extensive migration test on new application will reveal the new issues that were not found in the legacy application.

认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2018-11-28 16:01 | 显示全部楼层

使用道具 举报

回复
认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2018-11-28 16:01 | 显示全部楼层
What is Migration Testing?
Migration Testing is a verification process of migration of the legacy system to the new system with minimal disruption/downtime, with data integrity and no loss of data, while ensuring that all the specified functional and non-functional aspects of the application are met post-migration.
Simple Representation of Migration System:

使用道具 举报

回复
认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2018-11-28 16:02 | 显示全部楼层
Why Migration Test?
As we know, the application migration to a new system could be for various reasons, system consolidation, obsolete technology, optimization or any other reasons.
Hence while the System in Use needs to be migrated to a new system, it is essential to ensure the below points:
  • Any kind of disruption/inconvenience caused to the user due to migration needs to be avoided/minimized. Eg: downtime, loss of data
  • Need to ensure if the user can continue to use all the features of the software by causing minimal or no damage during migration. Eg: change in the functionality, removal of a particular functionality
  • It is also important to anticipate and rule out, all the possible glitches/hindrances that might occur during the actual migration of the live system.

Hence in order to ensure a smooth migration of the live system by eliminating those defects, it is essential to carry out Migration Testing in the Lab.
This testing has its own importance and it plays a vital role when the data comes into the picture.
Technically, it is also required to be executed for the below purposes:
  • To ensure compatibility of the new/upgraded application with all possible hardware and software that the legacy application supports. Also, new compatibility should be tested for new hardware, software platform as well.
  • To ensure all the existing functionalities works as in the legacy application. There should be no change in the way how the application works when compared to the legacy one.
  • The possibility of a large number of defects due to migration is very high. Many of the defects will usually be related to data and hence these defects need to be identified & fixed during testing.
  • To ensure whether the System response time of the new/upgraded application is the same or less than what it takes to the legacy application.
  • To ensure if the connection between servers, hardware, software etc., are all intact and do not break while testing. Data flow between different components should not break under any condition.


使用道具 举报

回复
认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2018-11-28 16:02 | 显示全部楼层
When is This Testing Required?
Testing has to be performed both before and after migration.
The different phases of Migration test to be carried out at the Test Lab can be classified as below.
  • Pre-Migration Testing
  • Migration Testing
  • Post Migration Testing

In addition to the above, the following tests are also executed as part of entire Migration activity.
  • Backward Compatibility Verification
  • Rollback Testing

Before performing this Testing, it is essential for any Tester to clearly understand the below points:
  • The changes happening as a part of the new system (server, front end, DB, schema, data flow, functionality etc.,)
  • To understand the actual migration strategy laid out by the team. How the migration happens, step by step changes happening in the backend of the system and the scripts responsible for these changes.

Hence it is essential to do a thorough study of the old and the new system and then accordingly plan and design the test cases and test scenarios to be covered as part of above the phases of testing and prepare the testing strategy.

使用道具 举报

回复
认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2018-11-30 15:24 | 显示全部楼层
Data Migration Testing Strategy
Designing the test strategy for migration include a set of activities to be performed and few aspects to be considered. This is to minimize the errors and risks that occur as a result of migration and to perform the migration testing effectively.
Activities in this Testing:
#1) Specialized team formation:
Form the testing team with the members having the required knowledge & experience and provide training related to the system that is being migrated.
#2) Business risk analysis, possible errors analysis:
Current business should not be hampered after migration and hence carry out ‘Business Risk Analysis’ meetings involving the right stakeholders (Test Manager, Business Analyst, Architects, Product Owners, Business Owner etc.,) and identify the risks and the implementable mitigations. The testing should include scenarios to uncover those risks and verify if proper mitigations have been implemented.
Conduct ‘Possible Error Analysis’ using appropriate ‘Error Guessing Approaches’ and then design tests around these errors to unearth them during testing.
#3) Migration scope analysis and identification:
Analyze the clear scope of the migration test as when and what needs to be tested.
#4) Identify the appropriate Tool for Migration:
While defining the strategy of this testing, automated or manual, identify the tools that are going to be used. E.g: Automated tool to compare source and destination data.
#5) Identify the appropriate Test Environment for Migration:
Identify separate environments for Pre and Post Migration environments to carry out any verification that is required as part of testing. Understand and document the technical aspects of the Legacy and New system of Migration, to ensure that the test environment is set up as per that.
#6) Migration Test Specification Document and review:
Prepare Migration Test Specification document which clearly describes the test approach, areas of testing, testing methods (automated, manual), testing methodology (black box, white box testing technique), Number of cycles of testing, schedule of testing, approach of creating data and using live data (sensitive info needs to be masked), test environment specification, testers qualification etc., and run a review session with the stakeholders.
#7) Production launch of the migrated system:
Analyze and document the to-do list for production migration and publish it well in advance

使用道具 举报

回复
认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2018-11-30 15:25 | 显示全部楼层
Different Phases of Migration
Given below are the various phases of Migration.
Phase #1: Pre-Migration Testing
Before migrating the data, set of testing activities are performed as a part of Pre-Migration test phase. This is ignored or not considered in simpler applications. But when complex applications are to be migrated, the Pre-Migration activities are a must.
Below is the list of actions that are taken up during this phase:
  • Set a clear scope of the data – what data has to be included, what data has to be excluded, which data needs transformations/conversions etc.
  • Perform data mapping between legacy and the new application – for each type of data in the legacy application compare its relevant type in the new application and then map them – Higher level mapping.
  • If the new application has the field that is mandatory in it, and but it is not the case in legacy, and then ensure that the legacy does not have that field as null. – Lower level mapping.
  • Study the new application’s data schema –field names, types, minimum and maximum values, length, mandatory fields, field level validations etc., clearly
  • A number of tables in the legacy system are to be noted down and if any tables are dropped and added post migration needs to be verified.
  • A number of records in each table, views should be noted in the legacy application.
  • Study the interfaces in the new application and their connections. Data flowing in the interface should be highly secured and not broken.
  • Prepare test cases, test scenarios, and use cases for new conditions in the new applications.
  • Execute a set of test cases, scenarios with a set of users and keep the results, logs stored. The same needs to be verified after Migration to ensure that legacy data and functionality are intact.
  • Count of the data and records should be noted down clearly, it needs to be verified after Migration for no loss of data.

Phase #2: Migration Testing
‘Migration Guide’ which is prepared by the Migration team needs to be strictly followed to carry out the migration activity. Ideally, the migration activity begins with the data back up on the tape, so that, any time the legacy system can be restored.
Verifying the documentation part of ‘Migration Guide’ is also a part of data Migration Testing. Verify if the document is clear and easy to follow. All the scripts and steps must be documented correctly without any ambiguity. Any kind of documentation errors, miss matches in the order of execution of steps also need to be considered important so that they can be reported and fixed.
Migration scripts, guide and other information related to actual migration needs to be picked up from the version control repository for execution.
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 Migration test. Ideally, it will be the same as that of the Migration time.
Generally, Migration activity defined in the ‘Migration Guide’ document includes:
  • Actual Migration of the application
  • Firewalls, port, hosts, hardware, software configurations are all modified as per the new system on which the legacy is being migrated
  • Data leaks, security checks are performed
  • Connectivity between all the components of application is checked

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 specified in the guide 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, 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 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 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.
Phase #3: 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:
All of these are documented as a test case and included in the ‘Test Specification’ document.
  • Check whether all the data in the legacy is migrated to the new application within the downtime that was planned. To ensure this, compare the number of records between legacy and the new application for each table and views in the database. Also, report the time taken to move say 10000 records.
  • Check whether all the schema changes (fields and tables added or removed) as per the new system are updated.
  • Data migrated from the legacy to new application should retain its value and format unless it is not specified to do so. To ensure this, compare data values between legacy and new application’s database.
  • Test the migrated data against the new application. Here cover a maximum number of possible cases. To ensure 100% coverage with respect to data migration verification, use the automated testing tool.
  • Check for database security.
  • Check for data integrity for all possible sample records.
  • Check and ensure that the earlier supported functionality in the legacy system works as expected in the new system.
  • Check the data flow within the application which covers most of the components.
  • The interface between the components should be extensively tested, as the data should not be modified, lost, and corrupted when it is going through components. Integration test cases can be used to verify this.
  • Check for legacy data’s redundancy. No legacy data should be duplicated itself during migration
  • Check for data mismatch cases like data type changed, storing format is changed etc.,
  • All the field level checks in the legacy application should be covered in the new application as well
  • Any data addition in the new application should not reflect back on the legacy
  • Updating legacy application’s data through the new application should be supported. Once updated in the new application, it should not reflect back on the legacy.
  • Deleting the legacy application’s data in the new application should be supported. Once deleted in the new application, it should not delete data in legacy as well.
  • Verify that the changes made to the legacy system support the new functionality delivered as a part of the new system.
  • Verify the users from the legacy system can continue to use both the old functionality and new functionality, especially the ones where the changes are involved. Execute the test cases and the test results stored during the Pre-migration testing.
  • Create new users on the system and carry out tests to ensure that functionality from the legacy as well as the new application, supports the newly created users and it works fine.
  • Carry out functionality related tests with a variety of data samples (different age group, users from different region etc.,)
  • It is also required to verify if ‘Feature Flags’ are enabled for the new features and switching it on/off enables the features to turn on and off.
  • Performance testing is important to ensure that migration to new system/software has not degraded the performance of the system.
  • It is also required to carry out Load and stress tests to ensure the system stability.
  • Verify that the software upgrade has not opened up any security vulnerabilities and hence carry out security testing, especially in the area where changes have been made to the system during migration.
  • Usability is another aspect which is to be verified, wherein if GUI layout/front-end system has changed or any functionality has changed, what is the Ease of Use that the end user is feeling as compared to the legacy system.

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.
Few tips for testers for writing the test cases for post-migration execution:
  • When the application is migrated, it does not mean that the test cases have to be written for the whole 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 tests 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.
  • If there is any new feature added in the new application, then new test cases should 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 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 happened.


使用道具 举报

回复
认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2018-11-30 15:26 | 显示全部楼层
Backward Compatibility Testing
Migration of the system also calls for the testers to verify the ‘Backward Compatibility’, wherein the new system introduced is compatible with the old system (at least 2 previous versions) and ensures that it functions perfectly with those versions.
Backward compatibility is to ensure:
  • Whether the new system supports the functionality supported in earlier 2 versions along with the new one.
  • The system can be migrated successfully from the earlier 2 versions without any hassles.

Hence it is essential to ensure the backward compatibility of the system by specifically carrying out the tests related to support backward compatibility. The tests related to backward compatibility needs to be designed and included in the Test Specification document for execution.

使用道具 举报

回复
认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2018-11-30 15:27 | 显示全部楼层
Rollback Testing                                                
In case of any issues while carrying out the migration or if there is a migration failure at any point of time during migration, then it should be possible for the system to roll back to the legacy system and resume its function quickly without impacting the users and the functionality supported earlier.
So, in order to verify this, Migration failure test scenarios need to be designed as part of negative testing and rollback mechanism needs to be tested. Total time required to resume back to the legacy system also needs to be recorded and reported in the test results.
After rollback, the main functionality and the regression testing (automated) should be run to ensure that migration has not impacted anything and rollback is successful in bringing back the legacy system in place.

使用道具 举报

回复
认证徽章
论坛徽章:
1054
紫蜘蛛
日期:2015-09-22 15:53:22紫蜘蛛
日期:2015-10-15 13:48:52紫蜘蛛
日期:2015-10-15 14:45:48紫蜘蛛
日期:2015-10-15 14:47:47紫蜘蛛
日期:2015-10-15 14:48:45九尾狐狸
日期:2015-09-22 15:53:22九尾狐狸
日期:2015-10-15 13:50:37九尾狐狸
日期:2015-10-15 14:45:48九尾狐狸
日期:2015-10-15 14:47:47九尾狐狸
日期:2015-10-15 14:48:45
发表于 2018-11-30 15:28 | 显示全部楼层
Migration Test Summary Report
The test summary report should be produced after completing the testing and should cover the report on the summary of the various tests/scenarios carried out as part of various phases of migration with the result status (pass/fail) and the test logs.
Time recorded for the following activities should be clearly reported:
  • Total time for Migration
  • Downtime of the applications
  • Time spent to migrate 10000 records.
  • Time spent for rollback.

In addition to the above information, any observations /recommendations can also be reported.

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

PostgreSQL中国大会,参会票抢购!

由 PostgreSQL中文社区与ITPUB联合主办的第九届《PostgreSQL 中国技术大会》将在北京隆重召开。PostgreSQL 作为功能最强的的开源关系型数据库之一,得到了越来越多企业的推广和运用,也越来越受到广大技术爱好者的欢迎和重视。这将是 PostgreSQL 的又一次交流盛会。
----------------------------------------
时间:2019年11月29~11月30日

点击报名>>
TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表