Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

This question already has an answer here:

A tool that migrates data from database A to B has been developed. The tool will be used to migrate all production data from version 1.0 of our app (operating on A) to version 2.0, currently being developed (operating on B). The schema may differ between each other. How are you going to make sure the application is working after migration? Provide your test strategy and sample test cases.

share|improve this question
2  
A complete answer? I attach my bank account number as well, ok? ;) –  SayusiAndo Jan 30 at 13:00
2  
StackExchange is not for demanding homework / interview answers. –  Lee Jan 30 at 13:02
4  
Welcome to SQA, nakul garg. If this is a homework/interview question, you should provide some evidence that you tried to work out the question on your own. If it is not a homework question, please provide specific details such as the database vendor and the framework that the tool is built on top of. –  user246 Jan 30 at 14:36
2  
-1 because you copied it directly from my answer, without even citing me: sqa.stackexchange.com/a/7463/1933 –  dzieciou Jan 30 at 19:52
add comment

marked as duplicate by dzieciou, Kate Paulk, Suchit Parikh, testerab Feb 2 at 15:42

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1 Answer

I would suggest that the most risk would be in the areas that change schema.

As a first step ask for a data migration plan. That is, a mapping from the current schema to the new schema. You can then verify that the database was migrated as expected from a data point of view.

In order to test this aspect properly you will need business domain knowledge of how the application works and which functions access this particular data. You should focus your testing around the application functions that access this data.

For the data that has not changed schema, I would suggest that a comparison/diff of the data from the original to the migrated database be done to verify that no data has been inadvertently changed. This should include both the data and the data model/schema.

You labeled this manual-testing. However, for such a change it would be nice to have an automated set of regression test cases for added confidence that the application can still read/write to/from the new database.

This is of course a simplified answer of a simplified question without much detail. In the real world, you would be worried about stored procedures, triggers, etc. and again the functionality that hinges from it.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.