Selecting a testing tool (6)


Having looked at some of the common reasons stated in favor of building tools in-house, let us now look at some of the reasons ascribed in favor of buying tools.

Reason – Buying will lead to faster deployment of the tool; a tool that is purchased will be faster to deploy.

Yes, when you consider that buying a tool cuts out the development costs involved in building it. Yet, the extent of quickness in deployment depends on your particular situation. 

There still needs to be due diligence towards selecting the right tool. Once that is done and a tool is procured, any needed customizations are to be performed. The tool then needs to be setup and configured, following which a detailed migration exercise has to be performed to move away from the existing tools and users need to be trained to work with the new tool. Time taken to accomplish the various tasks involved in deployment is also dependent on the extent of complexity. An important factor to consider would be the human acceptance of the tool. Just because a new tool is procured and setup, users & others associated with the roll-out will not automatically accept it. When a new tool replaces existing tools that are / were being used widely, you can expect some degree of resistance to the new tool. Comparisons are inevitable and in the initial days there are bound to be comments on the new tool vis-a-vis the existing tried and tested tools. Despite any shortcomings of an existing tool, users can be reluctant to adopting a new tool; more so, if they were involved / or had a stake in developing the existing tool. Customization, migration and acceptance are chief areas that can consume a lot of time.

I have come across teams that were reluctant (resistant would be more like it) to adopting a new tool. The new tool would technically help overcome drawbacks which the existing tool had – but folks had gotten used to the current tool, warts and all of it and were pushing back wider implementation of the new tool. They would find ways to delay implementation and after several deadlines for deployment had passed, the organization settled for a dual systems approach (use the old tool for some tasks and the newer one for some others). In some organizations, the transition to the new tool does happen but at a much later date than what was targeted.

Ultimately, the above elements will influence the amount of time it takes to deploy the tool you buy. Will it be faster than building a tool ? There is no definite answer. In some cases, it might be faster to build a tool while in other situations, buying a tool and deploying it will be quicker.


Image courtesy: Salvatore Vuono / FreeDigitalPhotos.net