Currently I am going to be testing (I am a Data Analyst) of a larger migration project where they are planning to migrate from DB2 to Oracle.
My question may be little broader; however any information which relates to the following questions would certainly be helpful.
1) How to validate both under Source and Target tables for:
-
Matching of Total Number of tables
-
Matching of Data fields under each
table
2) How to validate from Front end (UI), so that right data is getting populated under right table:
Challenge
- There are 500+ UIs, What is the
best way to test in an Optimized way
(to avoid any duplicate testing) - Should I also focus on table mapping
to UI screen
3) Any specific challenges I need to see under migration
- Datalock, Spacing issue, Noisy words
Best Answer
Normally for a straight forward data migration it is enough to know that all data is complete, valid and accessible for the application. Typically subtle differences may pop-up with some data-types like those with date, time, binary fields and long text fields.
In a straight forward data migration, data from table a field a goes to the new system in the same table, the same field. A good check to validate this could be done by computing a MD5 check-sum on all fields of all tables, both in source and target tables. Any difference here shows there is a problem in the migration procedure or software. Make sure to have the same formats in place for the MD5 computation; for example, make sure that the date formats are the same on both sides.
The application has to be tested, that's for sure. What the strategy should be is hard to tell, every application has it's own challenges. If all logic is known and standardized, it could work by making a simple test application that accesses all different field types and see how the interaction goes. In the end a regression test will be needed.