Points to Consider During Framework Migration
Framework migration is not something everyone would enjoy owing to the effort it takes to migrate and to get used to the new process/system. Nevertheless, it may be the inevitable in several cases such as these
- Migration to a newer version (eg Selenium RC to WebDriver)
- Migration to a new technology
- Unifying previously separate modules
- Change from a partially automated process to fully automated system
Areas to consider during framework migration
We have to focus on these three areas
- Migrating old Scripts and Configurations
- Test data migration
- History result migration to new system
We will look into each of them in detail.
Migrating Scripts and Configurations
If the new and old frameworks are similar, it would be easier to use a tool or script to migrate the existing scripts to the new framework. This is easier in cases like Selenium RC to WebDriver migration.
Generally, if the framework does not expose the core methods directly to the test scripts, but instead make use of wrapper functions, migration would be easier. In such a case, we just have to modify the framework class to migrate the script to the new framework.
In my previously company, we had different webdriver frameworks for each team based on their application. Some were good with window handling, some with ajax requests. So we had build a utility which would enable a test script to use one or more of these frameworks simultaneously with facility to replace them without affecting the test script.
Migrating Test Data
If you are migrating to a new framework, the framework should be written in such a way as facilitate easier data migration or using the same data format. In other cases, we can write a small script or utility to convert the data (usually text files) to the new format. Using Perl or Python would be better as they have better language processing capabilities compared to Java.
Converting data to the new format may not always be straightforward. When we were migrating SOAP scripts to a new framework, getting the data was a real pain. The data was stored in data files and they were parameterized with the parameter values in multiple places with the script.After spending a lot of time thinking of a easy way to get the data without much effort, we finally took the easier way of getting the data from the result HTML file which had the full input data.
Migrating Old Results
This is one area most teams tend to neglect. But it might become relevant in many cases to have a status of application health over time. Only the final result summary might be required, so do the result migration if possible. You can check this post to see why it is important to save your previous execution results in database.