HOW WE TEST

Each review, comparison and guide rests on one of four levels of evidence. We say which one, so you can weigh the verdict accordingly. A higher level adds to the ones below it.

1. Documentation research

What we do: We read the maker’s own documentation, pricing pages, changelogs and published research, and the independent sources around them.

What it tells you: What the tool is designed to do and what it costs, as stated by the people who make it.

2. Worked example

What we do: We build a small, real example with the tool, following its own instructions, and show the steps.

What it tells you: Whether the documented path works as described for a typical first use.

3. Recorded test

What we do: We run a defined task on a stated setup for a stated time, and record what happened, including what broke.

What it tells you: How the tool behaved for that task, on that setup, on that date.

4. Production use

What we do: We use the tool in our own work over weeks or months.

What it tells you: What it is like to live with: reliability, cost over time and the problems that only show up later.

What every test states

• What was tested, on what setup, for how long and on what date.
• What was outside the test, so the verdict covers only what we saw.
• Any link we have with the maker, including affiliate links.

The wider rules are in our editorial policy.