SPONSORS:






View RSS Feed

h_nivas

Code Upgrade & Migration Testing

Rate this Entry
by , 01-03-2016 at 07:04 AM (2282 Views)
When the code upgrade happens for a product from one version to another – it is quite obvious that existing features and functionalities are also disturbed and therefore there is a big ask to do regression testing quite thoroughly and properly. What we miss on most of the occasion is planning proper code migration or code upgrade testing.

In this post I am going to talk mainly about code upgrade/migration from one version to another and ensuring that these issues are contained during testing.

We can minimize these types of issues by planning migration testing properly. This planning should shape up well before the testing commences because we need to build test data with existing production code base which should be available in the QA environment where the testing has to be performed.

Some ideas are given below:
1. Plan release specific migration:
a. Include test cases for migration (from the areas of the application where there is impact because of the current changes)
b. Create test data in the test environments prior to the deployment of the new code
c. Execute test cases once the new code has been deployed

Use impact assessment to plan migration scenarios for the above case. (We have recently come up for one of the project that we are handling for our client)
2. Plan regression test cases:

a. The script should focus on using existing test data for major flows (in-flight transactions, existing records in different formats, clients and users, transaction records etc)
b. The test data should be set-up in the QA environment which should be same as in production
c. Test execution would then be recommended with production like data

3. Execution of migration scenarios with production data:
a. A separate environment can be set-up with production data (this can be refreshed before every major release for testing)
b. The migration scripts & regression to be executed with current production data

Point -1 can be implemented by extending the coverage by identifying test scenarios for migration because of the release specific implementation.
For point -2, we have to plan an outline for regression coverage.
For point – 3, we would need a separate environment or at least DB (copy of production data), which can be pointed to any of the QA environment for our testing.
However the above at times is difficult because of the compliance and regulatory restrictions and therefore either production like configuration or working on a sanitized DB is recommended.

We can brought a major difference by implementing these techniques.

Updated 01-05-2016 at 01:44 AM by h_nivas

Tags: None Add / Edit Tags
Categories
Uncategorized

Comments


vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
User Alert System provided by Advanced User Tagging v3.0.9 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Questions / Answers Form provided by vBAnswers (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
vBNominatevBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
Username Changing provided by Username Change (Free) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.
BetaSoft Inc.
Digital Point modules: Sphinx-based search
All times are GMT -8. The time now is 05:55 PM.

Copyright BetaSoft Inc.