Repeating some of the great suggestions above, I came up with…
- Developer buy in - will the developers use the tool too?
- Pipeline integration - will it be easy to integrate in the teams pipelines.
- Close to Application Code - does the tool complement libraries already used?
- Language - is it the same or similar family of languages that the organisation uses?
- Maintenance - who will maintain these tests and how easy is it?
- Updates - is the tool kept up to date and how often? Are there any risks to using it.
- Wider Test Strategy - could multiple teams use it? Or is it just for your team?
- Handover - if you were to leave the team and hand it over to someone new, how easy is it to do so?
- Type of Test - can the tool support different types of test? Component and End to End for example. Do you need that?
- Assertions - will the tool that drives the test need a separate assertion library.
- Hosting - if the tool needs a driver or a grid, where will it be hosted? How easy is that.
- Purpose - is it to find bugs, validate builds and/or describe the functionality? Which tools meet your specific purpose (or purposes)
- Authentication - does your app authentication make tests easier or harder. If you use OTP for example.
- Readiness - is your app stable enough yet to cope with test automation tooling?
- Tactical or Strategic - is the tool just to cope with a particular scenario (like I had a team whose app didn’t compile in live so I implemented basic build checks) or part of a wider endeavour,
- Level - is the tool aiming at the right level - you can use Cypress to perform API checks and E2E web tests, but should you focus on the cheaper API tests for faster feedback.
Phew! Don’t make me think. 