Daniel Weber, editor of Testing Experience

Daniel Weber edits every page on this site. He came to editing from the work the guides describe: writing test plans that had to survive review, keeping automation suites honest, running exploratory sessions against deadlines and, more recently, measuring AI components whose answers change from one run to the next.

Role

Editor, responsible for every guide and archive record

Background

Tester, test automation engineer and test manager

Worked in

Product and consultancy teams in Germany and the United Kingdom

Writes about

Test management, automation, agile testing, techniques, testing AI systems

Reviews against

ISO/IEC/IEEE 29119, the ISTQB syllabi, TMMi and each guide's sources

Contact

Through the contact page

Background. Daniel started as a manual tester on a payments product, where he learned that the most expensive defects were the ones nobody had written a test condition for. He moved into test automation, building and then pruning suites until they ran fast enough to be trusted, and later led test teams as a test manager, which is where he wrote the kind of plans, strategies and estimates the test management guides explain. Across those roles he worked on product teams and in consultancy, mostly in Germany and the United Kingdom.

Why he edits this site. Testing Experience magazine was part of how many testers of his generation learned the craft, and about a thousand websites still link to its issues. When the domain was relaunched in 2026 under independent ownership, the aim was a reference that deserves those links: guides a working tester can use the same day, and an honest record of what the magazine was. He does not speak for the original publisher and has no connection to it; the about page explains the relaunch.

How he writes a guide. Each guide starts from a question testers actually search for. He writes the direct answer first, then earns it with a figure or table, a worked example and a list of sources a reader can check, linked where the source has a page of its own. Worked numbers that are not from a named source are labelled as illustrative. Guides are reviewed against the relevant standards and books, and the review month shown on each page changes only when the guide has been read again in full.

What he will not publish. No vendor, product or company names in the guides, so they stay true as tools change. No sponsored content, paid links or affiliate arrangements of any kind. No text written to reach a length. On AI detection in particular, no claim that a detector score proves who wrote something: the guides on what a detector score means and authorship evidence set out why.

How he evaluates a claim. Before a sentence that asserts a number, a rate or a rule goes into a guide, it has to pass four questions. Where does it come from: a standard, a book, a published study or the editor's own experience, and the guide says which. Can a reader check it: the source is named and linked, or the arithmetic is shown. What does it hide: a rate is reported with its denominator and its interval, a coverage figure with what it counts, a cost model with the assumption it rests on. And what happens if it is wrong: a claim that could send a reader to accuse a student or to ship an untested pipeline is held to a higher standard than one that changes a template heading. Experience is allowed on the page, labelled as experience.

How to challenge a claim. Send the page address, the sentence and the reason, with a source if you have one, through the contact page. The editor replies within a week with one of three answers: the claim is corrected and the correction is noted at the foot of the page; the claim stands, with the source it rests on; or the claim is reworded as an opinion. Disagreements about method (whether a Wilson interval is the right choice, whether the pyramid is the right shape for a given system) are welcome and sometimes end up as a paragraph in the guide, credited to the reader who raised them if they wish.

Reading list. The books and standards the guides are checked against, in the order he reaches for them. For test management: ISO/IEC/IEEE 29119, Rex Black's Managing the Testing Process, the TMMi model document, and Kaner, Bach and Pettichord's Lessons Learned in Software Testing. For techniques: Lee Copeland's A Practitioner's Guide to Software Test Design, Glenford Myers's The Art of Software Testing, Boris Beizer's Software Testing Techniques, and ISO/IEC 25010 for the quality characteristics. For automation: Gerard Meszaros's xUnit Test Patterns, Humble and Farley's Continuous Delivery, and Graham and Fewster's Experiences of Test Automation. For agile: Crispin and Gregory's Agile Testing, Adzic's Specification by Example, Hendrickson's Explore It!, Bach on session-based test management, Gilb on inspection and Rothman on program management. For security: the OWASP Testing Guide and the OSSTMM. For AI and authenticity: the ISTQB AI testing syllabus, the NIST AI Risk Management Framework, the NIST overview of technical approaches to synthetic content, the C2PA technical specification, the IPTC photo metadata standard and the IETF specifications for signing structures, certificates and timestamps. The recommended reading page groups the same list by need.

Corrections and contributions. Errors are fixed within a week of being confirmed. If you spot one, or if you wrote for the original magazine and can extend an issue record, the contribute page explains what to send. Messages reach him through the contact page; he reads all of them and answers those that need an answer.