Results 1 to 6 of 6
  1. #1

    Database Migration Testing


    I am currently involved in a project that will be doing multiple database migrations to a single new application and database system. The feeding systems are varied and include Access, Sybase, SQL Server, each with various database schemas. All these applications will end up in a single Oracle database schema and with a new front-end application. I am looking for some recommendations on automating the testing of the data migrations. These would include processes such as:
    - comparing the feeding database values and the new database values to insure the migration has been accurate. This would include some limited logic because some translation of values will happen from one system to the other.
    - insuring that database integrity is maintained in the new system
    - check for business rules in the new database system (if value is x in this table, then value must be y in this other table).

    I am new to this type of testing software, so any recommendations on where to start is greatly appreciated.



  2. #2
    Senior Member
    Join Date
    Mar 2003
    Elkhart, IN, USA

    Re: Database Migration Testing

    Someone sharp with SAS might be able to help. I saw something similar in a different job than where I am now. The SAS programmer was able to exercise the power of that application to compare the different database outputs with each other.

    I am NOT a SAS programmer. SAS is NOT an automated tool. It is such a powerful 4GL that 4GL is not an adequate description.
    Michael L. Hovan

  3. #3

    Re: Database Migration Testing

    SAS is a wonderful tool for that, but if you do not have the budget you may even be able to do a similar job using Excel with ODBC access. It has a wonderful VBA programmability that will let you query databases, pull and store and manipulate data, and compare across multiple worksheets to do various analyses. A single worksheet holds up to 64K lines of data, but you should be able to sample a lesser set to validate the workings of the original databases against the workings of a new composite Oracle database, including business rules validation. Since I have no details, that is as much as I can suggest so far.
    Frits Bos, PMP

  4. #4
    Super Member
    Join Date
    Oct 2001
    Bucharest, ROMANIA

    Re: Database Migration Testing

    As discussed in similar topics, QA for data migration should contain different types of activities, each requiring different skills:
    -First it should be checked the mapping between each element of each database into the final one, including database constraints,...
    -Also, migration is usually performed using some scripts (at least partially). This process is usually a multi step process:
    - extracting the data from one database (not always the scope is all database content)
    - converting the data into new data model
    -populating the new database
    -enabling the constraints on new database

    Next step would be in this case testing of the migration scripts- a pure testing approach

    Next activity would be checking the complete migration. It's usually performed in different iterations, where first some small test data is migrating into new database, and the result is checked (in term of errors, migration completeness and new front-end functionality).

    During this phase a set of data validation and reconciliations criteria and scripts are developed in order to check the accuracy of critical data migrated.

    During this iterations you will discover that databases which will be migrated should be first cleaned up, because there are a lot of inconsistencies,.... Also not all data migration could be automated. Some parts will be migrated manually.

    Anyway, all this process should be defined together by database administrator, operations and support, QA, development, user representatives (this time is even more important than in "normal" testing)... but under coordination of a preject manager who knows something about migrations.

    I didn't touch some other possible implications of having interactions with other applications, interfaces,....

    Myabe it could look too scary. These were noticed during migration of billing systems. Maybe in your case it will be easier, but the idea is the same.
    Don't worry, be Happy!

  5. #5

    Re: Database Migration Testing

    I spent best part of a year doing QA of SQL to SQL DB migration which ended last year. We never even thought of automating as sql scripts were constantly changing, customer requirements changed etc... because was multiphased migration of users.

    I worked alongside Development a lot & found biggest issues were SQL Server problems - backing up Databases as well as Servers & Discs.

    Was one of more rewarding projects in last job but a lot of problems (bad planning, lack of proper h/w) but learnt a lot (how not to do) too.

  6. #6

    Re: Database Migration Testing

    In terms of technology to use, as suggested above, Excel with ODBC access is an option. Alternatively, if there is some Mercury WinRunner or QuickTest knowledge in your team, these tools can be used in conjunctions with ODBC and provide a number of built in functions for testing with Databases.

    In addition to this, if your company has any Extract Transform Load (ETL) applications, these might prove useful.

    Daniel_S's comments are probably more important - looking at 'what' to test rather than 'how'.



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
BetaSoft Inc.
All times are GMT -8. The time now is 07:53 PM.

Copyright BetaSoft Inc.