Is your QA team planning to migrate or has recently moved from HP Application Lifecycle Management (ALM) to Tricentis qTest? Any system or tool migration seems challenging and comes with a lot of work. So, I hope this article will serve as a guide on your migration journey 🚀
First, Let’s Look into Tricentis qTest:
What is qTest?
qTest is an enterprise-grade agile test management platform from Tricentis (an alternative from HP ALM).
Why qTest?
It has all the same functionalities as with HP ALM to manage all the artifacts within the Software Testing Lifecycle such as Requirements, Test Cases, Test Execution (includes reporting), and Defects. It also has integrations to Agile Management tools like Jira and VersionOne and to the free open source based test automation platform called TestProject. You can read more about their built-in integration with TestProject in the following resources:
- Official Docs: https://docs.testproject.io/testproject-integrations/qtest-integration
- Q&A post: https://blog.testproject.io/2020/03/31/testproject-and-qtest-integration-webinar/
Tool Migration Guidelines and Useful Tips to Consider
(1) Legacy Tool Availability – Most of the time, migration from one tool to another is not decided by only one team, but rather it’s for the entire organization to decide. Know who are the points-of-contact on the Enterprise level and ask: when will the existing tool be accessible? When can you start using the new tool? These details will help you in planning your next steps.
(2) Create a Plan and Timeline for Migration – Based on the availability of the existing tool, build a plan with the steps that need to be taken care of when moving to the new tool. Below is a sample template to follow:
| Tasks | ETC | Status |
| Inform affected teams
Identify users who needs access to the new tool Request access to the new tool Self-paced or schedule a training Identify test artifacts to migrate Start test artifacts migration Integration to other tools, e.g. Jira (if applicable) |
Set the estimated-time-of-completion (ETC) of each task in agreement with other teams affected by the migration | Not Started, In-progress, Completed |
(3) Determine What Needs to Be Migrated and What Does Not – Migration offers a good opportunity to re-evaluate test cases and artifacts to determine what is worth keeping and what no longer serves your needs. Based on my experience, we’ve listed down all the applications for the test artifacts currently kept in the existing tool. Consider migration of test artifacts in which:
- Applications are still active in Production – you may still need the test cases for regression testing.
- Applications with on-going changes or will have future changes.
On the other hand, test artifacts for projects that have been canceled or stale for an extended period of time – have not been included in the migration.
(4) Consider Implications to Your Current & Future SDLC – It’s important to consider that the new tool will have the ability to cover by establishing and maintaining connections on all SDLC activities from development to deployment. With that, qTest offers integration to Jenkins.
(5) Incorporate Test Automation Strategies – Check if the new tool will integrate with the existing and future Test Automation frameworks and tools. qTest offers vast documentation and resources on how to integrate into automation tools such as TestProject, Cucumber, and Postman.
(6) Learn about the tool – Does the new vendor offers training and support? How easy it is to on-board new users? As for qTest, Tricentis offers really good documentation, support, and training. They even provide Certificates of Completion once you’ve completed the qTest Specialist Level 1 training (just one factor to validate your knowledge!) 🎯
In Conclusion
Migration to a new tool may seem (at first) to be a painful process, but with proper planning, training, and working together to achieve one goal – it’ll be easier and smoother 😎
Reference: Quality-Center-Migration-Guide