Daniel Weber
Editor, 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.
Author profileUpdated
Report an error
Give the page, the sentence and the source that shows the error. Confirmed errors are fixed within a week.
Contact the editorBackground
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.
How he works
Start from the question
Each guide starts from a question testers actually search for, with the direct answer written first.
Earn the answer
A figure or table, a worked example and sources a reader can check stand behind it.
Put every claim through four questions
Where it comes from, how to check it, what it hides and what happens if it is wrong.
Review in full
The review month changes only when the guide has been read again in full.
Correct within a week
Confirmed errors are fixed and substantive corrections are noted at the foot of the page.
Why he edits this site
Testing Experience magazine was part of how many testers of his generation learned the craft. When the site was relaunched in 2026 under independent ownership, the aim was a reference worthy of the name: guides a working tester can use the same day, and an honest account 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. 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 placement 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, 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, 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.
