Six simple steps to migrate to a new Test management software while still keeping your sanity.
OK, if you are reading this, chances are that you are about to migrate to a new test management software solution. Let us start by wishing you Good Luck!!
Seriously, switching systems is not rocket science, but it is not a trivial task that can be taken on without previous thought and preparation.
You'll no doubt want to ensure disruption to your work is minimal, that the reuse of your existing assets is maximal, and most importantly you'll want to make sure that once you are done migrating, you and your team can continue working without disruption and actually see the immediate advantages of your new Test management software.
Going in, it's important to remember that no matter if you have an existing test management or ALM Solution in place, or if you are working with spreadsheets and documents, most probably you already have a process in place to manage your testing and quality operations.
Before you start
Whenever you migrate to a new test management system, you should approach this project in a way that will let you:
- Maintain and improve the positive factors of your existing process, while removing the no longer relevant or no longer valuable parts.
- Clean up and restructure your testing software (requirements, tests, runs, and issues) in a way that makes more sense with your team’s current work.
- Look for the best and simplest way to migrate your data to the new test management software solution you choose.
- Setup a process where all your team members are aligned, and there are clear ways to communicate
A good idea is to look for a test management tool that has a team with experience migrating from other systems and a work-plan framework to help customers migrate their process and software testing into the new test management software solution (like PractiTest).
See how easy it is to import your testing entities into PractiTest – Start a free trial and set up in minutes.
Here are some basic steps to consider while migrating to a new Test management solution, based on our experience:
1. Map your current process
The objective of this phase will be to understand who the stakeholders are and their needs.
This can be done from the definition of your project and its objectives. Going over the on-going status update reports and the end-of-project summary reports may assist as well.
Within this process, identify the things that work, and those that need to be improved as part of your new test management tool deployment.
2. Map your testing projects
The objective of this phase is to map your projects and define where the line separating each project resides. This will help you when planning the migration of your existing testing data, and especially when defining the organization within your new solution.
A testing project is defined by a group of requirements, test cases, runs and issues (collectively called testware) that refer to a specific release of your product and that are managed by an individual team in your organizations.
Each organization defines their testing projects in different ways: based on Products where each product has individual testing projects; or based on Releases, and within each “Release project” you list all the different products that are included within this logical group; or based on any other logical grouping defined by your company structure and working methodologies.
3. Identify things that are not relevant and remove them
The aim of this phase is to make sure your process answers your current needs, and you are not migrating irrelevant things.
Once you have identified your testing projects and your process, you need to take a moment and do a critical evaluation of your current state of affairs. Look for all the assumptions that used to be valid once but have since changed, or at constraints that are not in place any longer.
A useful tip for this process is to work with people who don’t belong to your team: either people from your company that are not part of the Testing Team; or people who are professional testers but may not be from your company.
4. Start migrating a limited number of representative projects
The best way to make sure you do this migration smoothly is by selecting a small number of representative projects (between 1 and 3) and start migrating them under controlled conditions, this is what many times is referred to as a “Pilot”.
For each of these projects perform the following steps:
a. Understand and map structure of the testware data
Make sure the testing project is correctly defined, and that you understand all the data, process and stakeholders that comprise it. It is important to migrate all the testware and the processes that are relevant to the project.
b. Define the customization of your new tools’ projects
This step will be relevant only if you choose to work with a flexible customizable tool such as PractiTest. In this phase, make sure all the different custom fields, filter trees, dashboards, and reports are defined correctly in your initial process. You will be able to modify them later on, but it is easier to import and populate this data while migrating your testware, especially in large scales. In case the new tool you chose does not have all the above, try aligning your testware to the new tools’ structure. This might limit your process later on as you will need to adjust your needs to the tool and not the other way around.
c. Migrate data
If you are currently working with excel, skip this one 🙂
Verify you can export the data from your existing system in a way that can be easily imported into PractiTest. This may require some small excel macros or other types of manipulations. Some tool providers (like PractiTest) have the option of working with their Professional Services team for this process.
d. Training
As with any other system that you introduce, there will be some training to be done with your team. The training should focus on the functionality they will be using the most, but without going over every single feature as to not overwhelm the users with too much information.
e. Start working and follow-up
Once your team/s start/s working, make sure to set up periodic meetings to review their work and gather their feedback on the tool and the process. These meetings can be every week in the beginning and then switch to every 2 to 4 weeks later on.
5. Set up a staged migration based on project release timeline
Once you run your pilot on a number of representative projects you can go ahead and create a migration schedule for the rest of your projects and teams.
Take into account your release timelines; it is recommended to migrate projects at the starting of the testing process. If possible, try to migrate teams at separate times so that you can invest the necessary time in helping their transition process.
6. Contact your new vendor for help
In case you chose a test management software that offers human Support and Services team, not only for technical issues but also for methodological ones, means you are not alone. We at PractiTest are proud of our professional and methodological support and the high response time we provide our clients. The support team of your new tool needs to “be there” to help and answer any questions you may have and to support you throughout your work.
Or as Stephen Musal, Freeman’s Lead QA Tester said: “The PractiTest team has always been great to work with. If I have found an issue they respond back quickly and very professionally. Without spending hundreds of thousands of dollars a year, we are getting a great product with great support that fits the needs of our department.”
