About Testing Experience
Who runs testingexperience.com, what changed at the 2026 relaunch, how guides are written and reviewed, the editorial rules and how to send a correction.
AboutUpdated
Propose a test or a guide
Tell the editor what you want tested or explained, and why.
How to contributeWhat the site is
Testing Experience is an independent site for people who have to decide whether to trust an AI tool, and for the testers who check such tools. Its test reports state the sample set, the procedure, the tool version and the date, so a result can be rerun. Its reference guides cover test management, test automation, agile testing and testing techniques, and it keeps an archive of the magazine of the same name, published from 2008 to 2014.
The relaunch
The original Testing Experience was a free quarterly magazine from a Berlin testing consultancy, edited by Jose Diaz, which stopped publishing after its 28th issue in December 2014. Testing Experience was relaunched in 2026 by a new, independent owner. This site is not the original publisher, has no connection to that company or its staff, does not hold the magazine's archive, and does not distribute the original issues.
It keeps the name because the name describes what the site is about, and it keeps a page for each well-known issue so that readers who remember the magazine can see what it covered and where the subject lives now.
Who runs the site
Daniel Weber is the editor responsible for every page on the site. He has worked as a tester, test automation engineer and test manager on product and consultancy teams in Germany and the United Kingdom, and writes the guides from that experience and from the standards and books each guide cites.
Every guide and issue record carries his byline and the month it was last reviewed. His editor profile sets out his background and how he works, and he can be reached through the contact page.
How guides are written
Each guide starts from a question a working tester actually searches for, states the direct answer in a quick-answer card, and then earns that answer with a figure or table, a worked example, and sources named so that a reader can check them. Guides are reviewed against ISO/IEC/IEEE 29119, the ISTQB syllabi and glossary, the TMMi model and the books in their sources list. Numbers in worked models are labelled as illustrative where they are not from a named source, with an instruction to replace them with the reader's own data. Tool tests follow a separate, pre-registered protocol and scoring rubric, published on how we test.
A guide begins as a question written the way a tester types it into a search box, and a one-line answer the editor is prepared to defend. The draft is built outward from that answer in a fixed order: the figure or table that opens the page, the worked example with its numbers, the comparison table, the limits, and only then the prose that connects them.
Before publication each guide is checked against one named standard or book: the test management guides against ISO/IEC/IEEE 29119 and Rex Black's Managing the Testing Process, the technique guides against Lee Copeland's A Practitioner's Guide to Software Test Design and the ISTQB syllabi, the agile guides against Crispin and Gregory and against Adzic, and the AI and authenticity guides against the ISTQB AI testing syllabus, the C2PA technical specification and the NIST overview of synthetic content. A claim the check cannot support is cut, or rewritten as an opinion and labelled as one.
How figures are built
Every figure and table is drawn from data that is either cited or declared. Where a figure shows published numbers (the relative cost of a defect by stage, a false positive rate from a named study) the source is in the guide's list and the figure repeats the value without smoothing it.
Where a figure shows a worked example, the counts are invented but realistic, the caption says so, and the arithmetic is shown in the text so that a reader can substitute their own numbers. Figures are drawn as plain vector graphics served by this site, with the values in the markup, so that they read correctly in a screen reader and print without colour.
Editorial rules
- 01Guides name no products so they stay true as tools change. Evidence pages name a product only to report what a university, study or vendor has published about it.
- 02Test reports name the tool, the version and the date because a result is only useful if you know what produced it.
- 03No tool maker pays for a test sees a result before publication, or buys a placement or a better position in a table.
- 04No advertising and no sponsorship Some links to tools we have tested may carry a referral code; a link never changes a result.
- 05No cookies and no cross-site tracking; the only measurement is cookieless page statistics in aggregate.
- 06Every source is named so that a reader can check it.
- 07Every page is signed with the editor's byline and the month it was last reviewed.
- 08Nothing is written for length and a page that cannot meet its floor honestly is cut.
- 09Confirmed errors are fixed within a week and substantive corrections are noted on the page.
What the site will not publish
The archive
Each issue page gives the date, the theme where it is known and the guides on this site that continue the subject. Nothing is asserted about an issue's contents beyond its known theme, and an author is named only where that is established.
An issue page states only what a reader can check elsewhere: the issue number and date, the theme where it is known, and an author only where that is established. Contributions from people who wrote for or hold the magazine are marked as contributed, so that the two kinds of statement never mix. The rule costs the issue pages some detail, and it is what keeps them honest.
If you were an author or reader of the magazine and can correct or extend an issue page, the contribute page explains how.
Corrections
Errors are fixed within a week of being confirmed, and the page's review month is updated. Substantive corrections are noted at the foot of the affected page.
The workflow is fixed: a report arrives through the contact page with the page, the sentence and a source; the editor confirms it against the source within a week, or replies to say why it does not hold; a confirmed error is corrected, the review month is updated, and a substantive correction is noted at the foot of the page with the date. A correction that changes a figure or a table triggers a re-read of the whole guide before the review month changes.
