| || |
Database migration testing
We are changing /upgrading our database architecture and want to use an automated tool to test the database migration .We envision the tool helping us out with creating database queries, running those queries (possibly unattended) , and using something like a diff tool to validate the results .
What is the best tool for that Silk test or Winrunner ??
Performance Testing Engineer
Gelco Information Network
Fawad A Rana
OptumHealth-A Division of UnitedHealth Group
Re: Database migration testing
To integrate the back-end data, a conversion program must often translate the data from one application into the proper format for the other. When validating proper data integration, the tester typically performs system testing on the conversion program to validate that it enforces the data rules, business rules, and system requirements for the application.
In addition to formatting, the conversion program must also consider the business rules and system requirements for each application. In our example, the two datasets will be merged into a single inventory. Data from Beta Widgets will be converted and imported into the database used by Alpha Widgets. Alpha Widgets has a business rule that requires a telephone number for each customer record, so the conversion program should check the customers from Beta Widgets for phone numbers before simply importing the records. Any record that doesn't follow the business rules should be noted, so that someone can resolve those issues later.
Data Validation Process
Ideally, application data from the production environment should be used to perform validation in the test environment. This provides an accurate reflection of the data range that the conversion program will encounter. If actual data cannot be used, then the tester must create a set of data that properly exercises the boundaries of the business rules.
In our hypothetical scenario, if the maximum length of the Last Name field is 40 characters, then data used during the test should probably include instances where the Last Name is blank, one character, 40 characters, 41 characters, and 150 characters. This would cover scenarios where the field is null, very small, in range, out of range, and very large. After the conversion program has translated some test data, the analyst can run queries to quickly parse the database and examine the results from a high level.
For example, let's say the Alpha Widgets database is set up with one record per physical product, while the Beta Widgets database has one record per product title with a row that indicates the quantity. After data is converted from Beta to Alpha, the analyst could run a query comparing the count of rows in the Alpha database to the sum of the quantity fields of the imported data from Beta. If there is a discrepancy, then the conversion program failed to import all of the data.
With small conversions, the data can be validated at the row, field, or character level. However, if the volume of data is larger, it can be impractical to manually validate all of the data by hand. In these cases, automated testing may be desirable. This can include data comparison tools, scripts created in record/playback tools, or statistical analysis software that can analyze trends in the data.
Every good data conversion process should include a rollback method, which should also be tested. What happens if something goes wrong during the implementation, or if problems are reported afterward? In such an emergency, the system must be able to restore itself to its original state before the conversion. Remember, the two separate systems will probably still work on their own. Rolling back to two systems that work is better than having an integrated system that doesn't.
When verifying this part of the process, you should test several conversions and rollbacks to ensure data integrity. Additionally, if partial rollback is allowed, test the process for proper version management. For example, you could convert some data, rollback a portion of that data, then convert a set of data that includes some new data and some previously rolled back data. Lather, rinse, repeat.
Finally, in some cases, not all of the data will be brought over from the previous database. The tester will need to ensure that the conversion program didn't migrate any unwanted data. Some data will be missing from the old database, so fields will be blank when the records are migrated. Sometimes data will be converted while the old system is still active, causing issues with data version management. All of these deviations from a full data conversion should be specified in the requirements, and then covered in the conversion program validation effort.
- published in "Rest Assured." New Architect. July 2002.
Tim Van Tongeren