The publication / how we test
A method you can inspect.
Hands-on testing and source verification answer different questions. We make the distinction explicit.
For a source-backed guide
We verify the feature, installation instructions, limitations, and relevant security advice against current primary sources. Original examples explain the workflow; they are labelled as examples when they have not been run.
A source access date means documentation was checked on that date. It does not mean the software was used. We avoid adding a “last tested” date to guides without a recorded test.
For a hands-on evaluation
Before running a comparison, define the task, input, success criteria, versions, environment, and constraints. Use equivalent inputs where feasible. Save output and screenshots from actual runs, including meaningful failures.
Evaluate the result against the task: correctness, necessary human intervention, usability, time where measured, and cost where actually incurred. Do not extrapolate one result into a universal performance claim.
What we publish with a test
Describe the method, test date, version, scope, and limitations. Link evidence where safe and useful. Redact secrets, personal data, and material we do not have the right to publish.
Pricing is checked separately from product behavior. A pricing-check date is not a test date. When a feature or plan changes, repeat the relevant checks before updating the recommendation.