The paradigm differences in DEV and TEST staging servers.
Test staging extracts all the data in the destination data model alignment. Whereas DEV will need a differential extraction and progressive transformation of data.
Test staging will only bring in the records that SHOULD be in the destination. Whereas DM extraction should get in all the records from Source and log a comment on any exceptions or failure migrations.
Test staging will be built with the primary Key/constraints based on the destination model. The repeated test efforts should be a mere LEFT/RIGHT/INNER join validations between TEST STAGING and DESTINATION. Anything missed or in excess is a bug kind of approach.
Test Staging tables are usually build with a Second NORMAL form or Third Normal form based on the rules/ Index of migration. With an exception of DATA CONSITENCY
I. Build the test staging
Building the test environment (Test staging server)
In any project that has a data + functional changes happening in parallel the following needs to be ensured with regards to designing the test environment/data base.
Isolating the migrated data from SIT test manipulation. Unless this is done we never know what was a Data transformed by the Data Migration VS what was a bad data caused by functional test tweaking.
Get all the Source/Staging and Destination Databases on a single server to foster better performance in high volume data test.
Instrument complete set of the daily jobs and other Procedures that recalculates data in the system (Desired/Undesired changes roll back).
Staging server should be planned to accommodate a Space GROWTH by atleast 200%.
All the test results for each refresh should be available on the test staging to see the differential data changes associated with code fixes.
Scope VS Complexity VS Refresh Ratio:
Source DB counts Number of Master DB destination Complexity of Data in terms for transformations Minimum No. of Refreshes required in SIT Suggested test span on each refresh
1 1 Apple to Apple/upgrades/SQL to Oracle data transformation 2 5 days
2 1 Less than 10 data merge/split DM rules 4 5 days
>2 1 Less than 10 data merge/split DM rules 4 5 days
>2 >1 More than 25 data merge/split/transform DM rules spanned across more than 50 tables 7 10 ays
Test staging extracts all the data in the destination data model alignment. Whereas DEV will need a differential extraction and progressive transformation of data.
Test staging will only bring in the records that SHOULD be in the destination. Whereas DM extraction should get in all the records from Source and log a comment on any exceptions or failure migrations.
Test staging will be built with the primary Key/constraints based on the destination model. The repeated test efforts should be a mere LEFT/RIGHT/INNER join validations between TEST STAGING and DESTINATION. Anything missed or in excess is a bug kind of approach.
Test Staging tables are usually build with a Second NORMAL form or Third Normal form based on the rules/ Index of migration. With an exception of DATA CONSITENCY
I. Build the test staging
Building the test environment (Test staging server)
In any project that has a data + functional changes happening in parallel the following needs to be ensured with regards to designing the test environment/data base.
Isolating the migrated data from SIT test manipulation. Unless this is done we never know what was a Data transformed by the Data Migration VS what was a bad data caused by functional test tweaking.
Get all the Source/Staging and Destination Databases on a single server to foster better performance in high volume data test.
Instrument complete set of the daily jobs and other Procedures that recalculates data in the system (Desired/Undesired changes roll back).
Staging server should be planned to accommodate a Space GROWTH by atleast 200%.
All the test results for each refresh should be available on the test staging to see the differential data changes associated with code fixes.
Scope VS Complexity VS Refresh Ratio:
Source DB counts Number of Master DB destination Complexity of Data in terms for transformations Minimum No. of Refreshes required in SIT Suggested test span on each refresh
1 1 Apple to Apple/upgrades/SQL to Oracle data transformation 2 5 days
2 1 Less than 10 data merge/split DM rules 4 5 days
>2 1 Less than 10 data merge/split DM rules 4 5 days
>2 >1 More than 25 data merge/split/transform DM rules spanned across more than 50 tables 7 10 ays
No comments:
Post a Comment