How we test
What we actually do before a guide or a recommendation goes up.
A guide that has not been run is a guess with formatting. Here is what happens before one goes up.
For a how-to or a fix
- Every step is performed, in order, on a machine running the version named at the top of the page.
- The version is recorded - Windows build number, Android version and manufacturer skin, or app release. Most broken guides are not wrong; they are right about a version you are not running.
- Failure modes are noted. If a step commonly fails, the page says what the failure looks like and what to do next, instead of assuming it worked.
- Nothing destructive is recommended casually. If a step can lose data, the warning comes before the step, not after it.
For a tool review or comparison
- We use it for real work, not for a demo. The first hour of any tool is marketing; the second week is the review.
- We say what it is bad at. A review with no weaknesses in it is an advertisement.
- Pricing is checked on the day of publication and dated, because it moves.
- Free tiers are tested as free tiers, not as trials of the paid plan.
What we do not do
- We do not republish a vendor feature list as a review.
- We do not pad a list to ten items because ten ranks better than four.
- We do not recommend a tool we have not opened.
When we cannot verify something
It gets labelled. An unverified claim marked as unverified is useful; an unverified claim written confidently is not.
Corrections
Corrections are dated and stated on the page. If a guide stopped working because the software changed, the page says so, and says when.