How we evaluate 193 tools across 17 categories

A tool earns an entry if it is actively maintained, has real users outside its own company, and does something a team could reasonably build a process around. That is deliberately a low bar for inclusion and a high bar for how it gets written up.

Abandoned projects are removed rather than left with a warning. Where a tool has been acquired or its licence has changed in a way that affects buyers — and that has happened repeatedly in this market — the entry says so.

A directory that only lists features is a price list with extra steps. The most useful sentence in any tool review is the one that tells you where it falls down, because that is the thing you will discover in month three otherwise.

The rule is simple: if we cannot name at least two concrete limitations, we do not understand the tool well enough to recommend it. "Has a learning curve" does not count. "The proxy architecture breaks on apps with strict CSP" does.

The headline price on a vendor page is rarely what determines your invoice. Device clouds bill per parallel session. Visual testing bills per screenshot. Analytics bills per event or per tracked user. Test management bills per Jira user, including the ones who never open a test case.

So every entry records the starting price and, separately, what actually drives the bill. That second field is the one worth reading before a procurement conversation.

Figures are indicative and were last reviewed August 2026. Vendors change pricing frequently and enterprise pricing is negotiated. Always confirm on the vendor's own page — every entry links directly to it.

Each tool carries an adoption rating from one to five. It reflects how widely the tool is deployed and how easy it is to hire for — not how good it is. A category standard can still be the wrong choice for you, and a niche tool can be exactly right.

We do not publish an overall quality score. Any single number that ranks Playwright against Tricentis Tosca is measuring nothing, because they are bought by different people to solve different problems under different constraints.

The finder treats your answers as two different kinds of input. Hard requirements — a budget ceiling, self-hosting, open source, organisation size — are filters. A tool that violates one never appears, even if it would otherwise be the obvious answer.

Everything else is weighted. Language overlap with your stack, platform coverage, whether authoring matches who will actually maintain the tests, and adoption all contribute. A tool whose primary purpose is the category in question always outranks one that covers it as a secondary feature, and the results say so explicitly when that is the case.

Each recommendation shows the reasons it scored well and the caveats that apply to your specific answers. Nothing is stored, no account is required, and the result is encoded in the URL so you can share or bookmark it.

No vendor pays for placement, ordering, or a more favourable write-up, and no vendor reviews an entry before it is published. That includes partners, described below.

2 of the 193 entries carry an affiliate link, and each one is labelled on the entry itself rather than in a footer. The other 191 link straight to the vendor and earn nothing — mostly because they are open-source projects or are sold by a field sales team, neither of which has a programme to join.

Which entries those are is decided by whether the vendor runs a public affiliate programme, not by what they pay. A commission never changes the ordering, the adoption rating, or the wording of a limitation. Documentation and repository links are never monetised at all, because those are the links you follow to evaluate a tool rather than to buy it.

Reader reviews and the stack finder are unaffected either way: the finder scores on your answers and never sees whether a tool is monetised.

We do not currently hold a commercial partnership with any vendor.

So partnerships carry more disclosure, not less. Every guide about a partner opens with a label saying so, before the first paragraph. Partner entries keep their limitations like every other entry, and guides about them follow the same rule. A partner does not write, review or approve anything we publish about them.

Partnerships are only entered into with vendors whose products we know and respect, and they never make the stack finder, the catalogue ordering or an adoption rating move.

Facts change: prices move, licences change, companies get acquired, features ship. If something here is wrong or out of date, it should be fixed rather than defended.

The most common source of error in a catalogue this size is pricing drift, followed by acquisition-driven roadmap changes. Both are flagged in entries where they are known to have happened.