How do you identify if a tool is no longer fit for purpose? – 30 Days of Tools, Day 30

📆 30 Days of Testing
,
1

Many congratulations, you made it to Day 30 of the 30 Days of Tools challenge! :trophy::relieved::smiley:

We hope you’ve enjoyed the experience, learnt a whole tonne of stuff and connected with others in the community.

How do you identify if a tool is no longer fit for purpose?

  • Sometimes you just got to part ways with a tool. How do you spot when it’s time to call it quits?
  • What was the moment you realised the tool was no longer fit for purpose? What did you do next?
  • Share examples of how you’ve moved from one tool to another

Feel free to reply to this post and share wherever you like, on the MoT Slack, LinkedIn, Twitter using #30DaysOfTools, Racket, your blog, with your team and any place you feel might inspire yourself and others to do the same. Let’s learn from each other throughout October. Visit the 30 Days of Tools page and select the “Subscribe to Topic” button to receive each daily challenge direct to your inbox.

2 Likes
2

If it creates more problems than it solves, for instance, if you’re using Open Source software that has been abandoned by the maintainers and you have to spend a lot of time hacking it to make it work, then it might be time to search for alternatives.

I pondered the idea of using Postman for all my automated tests, but I decided to use it just from basic smoke tests and use a more configurable tool for regression testing and automating the business-important scenarios.

A couple of years ago I remember moving from Write to Jira, at first it felt a bit uncomfortable (I guess any change is) but gradually it felt like the right choice. It’s important not to get too emotionally attached to tools, like the Jedi and the Buddist say: attachments are forbidden - security people might say the same! :sweat_smile:

2 Likes
3

When it becomes to expensive, or when the ROI isn’t worth it anymore.
As @mirza also said, when it creates more problems then you originally have.

When there are things you cannot solve with the tool.

We moved from protractor to Cypress, just because it’s being deprecated. Also because it didn’t solve all issues and the maintenance with huge because of all the flakyness :stuck_out_tongue:

1 Like
4

One thing to try is to document all the problems you find in the tool. You can keep the doc to yourself or share with the team if needed. The moment you notice a major issue, add it to your document immediately. Write a 2-3 line summary with some keywords if you don’t have time. You can use the summary to add more details later.

Once the tool has become a major problem instead of major benefit, then you can use the doc to justify removal of the tool to upper management. If they don’t care, then you can use it in your next job to block the adoption of the tool.

PS - IMO the so called “low code”, “no code” testing tools deserve to be rejected. They seem nice, at least initially, but they are likely to be a loss than a benefit. I’d avoid working for companies whose main or only testing tool is low/no code. That way, we can avoid doing such documentation in the firs place.

1 Like