This is a guest posting by Nishi Grover Garg
We are all forever on the lookout for better and faster ways to achieve our quality goals, and adding new tools to our suite often seems like a good way to do that. However, introducing a new tool to an already working environment may be tricky and could require some special considerations.
Let’s look at five common mistakes teams make when adopting a new tool so we can be sure to avoid them.
1. Jumping In Without a Proof of Concept
Every tool has its strengths and shortcomings, and even though multiple tools may be intended for the same purpose, they all may not suit your context. Jumping into a new tool just because you heard it may solve problems like yours may not be the best approach.
As a first step, you should organize a comparison of similar tools by using them all in your own project’s context and seeing how they serve your purpose. You should do a brief analysis and pick the one that best fits your need. This initial proof of concept will help you get the most from the tool later.
2. Not Testing the Tool in a Pilot Project
The people involved in the initial comparison, analysis, and proof of concept for the new tool can then begin the adoption of the tool in a pilot project. The aim of this will be to begin using the tool in your day-to-day work so you can look at the benefits by the end of the cycle.
In an agile context, it could mean using the tool for a sprint so that at the retrospect at the end you can analyze what was achieved and how effective the tool was. The people involved are the ones who know about the tool in brief and will be looking at the best ways of using the tool in the project’s context throughout the cycle. At the end of the cycle, they can devise a list of best usage practices that can act as guidelines for other teams later.
The framework for the usage of the tool should be set up during this initial pilot project, including the servers and environments needed, governances and rights, and usernames and profiles, along with instructions on setup and usage for everyone.
3. Performing the Wrong Profit Analysis
If we are adopting a new test automation tool, we cannot measure the success of the pilot team by the issues found using the tool in the first sprint. We also can’t analyze the benefits of a static analysis tool in a continuous testing environment by the number of times the build passed or failed.
The success of the pilot project is measured in terms of the efficiency of the team in using the tool in their day-to-day activities and its resulting benefits. The focus is not how the team performed during that sprint, but on how well the tool fits into their lives and what they could achieve out of its usage.
4. Rolling Out Adoption All at Once
If I decide to adopt a new test management system and announce to all teams to begin using it today, it will just result in chaos. Even if they are given the necessary setup and environment, people do not know how to use the tool, what features to use when or how best to realize its benefits.
That is why, after the necessary pilot project, you should then incrementally roll out the tool to other teams. The lessons from the pilot then act as a guideline for the other teams, and the people involved in the pilot project can train the other teams one-by-one on the use of the new tool and the best practices according they discovered. Any issues faced after that can be resolved by mutual cooperation among the teams.
Having sufficient time for training and learning is imperative to get every team’s support and consensus, so it’s wise to provide enough hand-holding with the tool until things begin running smoothly.
5. Neglecting Continuous Learning
Even after the tool is adopted and projects are running back on track, there may be new things we discover. Teams face issues and find solutions, and they also can uncover better practices, features, and uses of the tool. The tool also may evolve, with updates bringing new challenges or opportunities. It is important to keep track of all such developments and have a common platform to share these discoveries.
We should create open channels of communication where teams can share their findings and better practices and encourage the adoption of common ways of working with the tool throughout the organization. This is a continuous learning cycle.
We should also keep an eye open toward market trends and other new tools and keep analyzing whether they could solve the problems we have in a better and more efficient way. There is no point being stuck with a tool that you don’t love!
Software Test Automation Solution Buyer’s Guide
Find the right tool for your team
Nishi is a corporate trainer, an agile enthusiast and a tester at heart! With 11+ years of industry experience, she currently works with Tyto software as an Evangelist and Trainings Head. She is passionate about training, organizing testing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
