Some things you might like to consider:
- How likely is it users will use the feature that needs your second tool?
- How likely is it that there will be regression problems with the GUI interface and those features? (even if the application has not been released, if that part of the system has been problematic, it’s likely that it will continue to be problematic).
- How much extra work is the second tool likely to add for your team, and does the ROI of that work justify purchasing and using the second tool? (that is, if it will take you 50 hours to add the automation you need using tool 2, and then 5 hours per week to maintain it, but you could do the same tests manually in 2 hours per week, it’s probably not worth automating)(the numbers are random)
- How much of the functionality you’re planning to automate with the new tool is covered by unit tests?
If after you’ve considered these factors (it’s not a complete list, but it’s a decent starting point) it looks as though the second tool will be worth your while, then it’s a good idea to use it. If it looks as though you’re going to spend more time modifying your tests and trying to figure out flaky tests, then it probably isn’t a good idea.
Either way, you’ll want to start with an evaluation version (if the tool is not free and open source) and see if it will work for you before you make the decision.
If you do decide to use it, make sure to build the tests into your CI pipeline so they are run regularly, if possible