Data is vital for any kind of application. Maintaining the quality & integrity of data is a task of utmost importance and hence any change related to data calls for a formal strategy for testing. The strategy would depend on factors like business criticality of the data, time available, budget etc. and needs to be tailored according to the application itself.
What is Data Migration or Conversion?
Data Migration, in very simple terms, means moving the data from one environment/system to another. It can be done for variety of reasons like upgrading the version of existing DB, change from one DB to another, upgrades in servers, relocation of data centers etc.
For a complex application with large volumes of data, this can be quite a challenging task. The scope of the project needs to be analysed carefully to craft the testing strategy. Data migration projects can be carried out in big bang approach as well as in incremental fashion.
- Data corruption: Its highly likely that data gets corrupted during migration. Target DB might allow loading of corrupt data but the application will crash as a result.
- Loss of data: Doesn’t need much explanation to define how important it is to not loose any data.
- Semantics Risks: These refer to the faults which can happen if units for some field are not same in source and target Databases. for example unit for currency in source and target DB might differ. Data inconsistency issues would arise if 1 INR is referred to as 1 USD in the two DBs. Another example could be one DB considering the currency filed upto two decimal points as opposed to three in the other.
- Extended Downtime: If the time taken to do the migration or conversion is long, it may increase the downtime for the application. Applies more to application with strict SLAs like banking applications.
- Orchestration Risks: The dependency between various objects has to be considered while migrating the data. A person’s details cannot be migrated before migrating the person object itself. The order of migration activities is important.
- Performance of DB after the migration/Conversion.
- Application Stability Risk: After the migration, user should be able to perform valid expected operations on migrated data. Similarly, creation of new data and related operations should be possible. Migrated data should not hamper application’s functionality in any way.
- Operational Risks: If the source DB is used while migrating the data, the data might change leading to inconsistency of data in target DB. It can also cause locking of tables.
- Target Parameterization Risks: These arise if the target application changes during migration and it becomes incompatible to the migrated data.
- Assessing the existing Data: The existing data need to be assessed in terms of quality and existing issues. It can be huge pitfall if the nature and behaviour of existing data is unknown or ambiguous beforehand.
All the above risks can be mitigated or catered to by mitigation techniques and strategised testing:
Tests for Data Integrity: The database is checked for any missing data to ensure that all data has been migrated successfully from source to target. Apart from this, testing has to keep an eye on any unwanted data appearing in the target database. UI tests and processing of data will also help identify some issues.
- Tests for Semantic Risks: This can be done by comparing the target and source DBs using suitable techniques. Depending on the application, UI tests can also pick up some issues. Sometimes, processing of migrated data might help catch issues.
- Corrupt Data: This can be the easiest or the most difficult part to test for depending on the complexity of the application, which data gets corrupt, user’s familiarity with the application and so on. Like mentioned in above two points, UI Tests and processing of data are the best testing ways to catch bugs in this area. Integration tests can also be helpful depending on the application.
- Operational Risks: These risks are to be managed by following a proper process.
What does Testing team need to do/know/take care of?
Understand how your application plays with the data, how can it create/transform/use/process the data.
- Identify all the interfaces to and from your application.
- Save a copy of source and target DBs so you can redo your tests any time on a fresh copy.
- Involve the stakeholders and Business people in the migration plan.Its very important to get the right people participate at the right time.
Data Migration Testing
Typically, testing for Data Migration is of two types:
- Data Validation
- Migration Run Tests
Data Validation Tests
These tests aim to :
- a) Check Completeness and Integrity of data.
- b) Find Semantic Errors
- c) Verify Application Stability
- d) Verify all Interfaces with the application.
- e) Perform Appearance Tests which shortlist business critical objects fpr testing after consultation with Business experts.
Migration Run Tests
These validate every aspect of the migration programs from extract, filter & transform and load to the target.
These can be:
— Full Migration tests – Run using the full data set and help find out the time required for the migration.
— Partial Migration Run Tests – These can be done to speed-up the development cycles and used to guesstimate the expected execution time which may or may not be accurate.