Recommended Reading for Software Testers
The original site had a recommendations page and a links page. This is their replacement: the books, standards and communities that are still worth a tester's time, grouped by what you need them for.
A reading list is only useful if it says why. Each entry below earns its place for one reason a working tester would recognise, and the list is deliberately short. It is organized by need rather than by type, because nobody wants 'a standard'; they want to know what to cite when a customer asks for a test process, or what to read before their first exploratory session. No vendor documentation appears here, and no entry is an affiliate anything; titles and authors are given so that you can find them wherever you buy or borrow books.
For the vocabulary and the exam. The ISTQB Foundation Level syllabus and its glossary are free, current, and the shared language of the profession in Europe and much of Asia. Read them for definitions, not for thinking. ISO/IEC/IEEE 29119 is the international test process and documentation standard; part 3 (test documentation) is what to cite when a regulated customer asks what a test plan must contain, and it replaced IEEE 829, which many organisations still reference. This site's glossary follows ISTQB usage where a term is defined there.
For test management. Rex Black, Managing the Testing Process, remains the most complete treatment of running a test effort end to end, and it is the book associated with a PDF the original site hosted. Cem Kaner, James Bach and Bret Pettichord, Lessons Learned in Software Testing, is 293 numbered lessons and the best book to hand a new test lead. Erik van Veenendaal's work on the TMMi model and the TMMi Foundation's freely available model document are the references for test process improvement.
For thinking about testing. Michael Bolton's blog and his writing with James Bach on rapid software testing are the sharpest current arguments about what testing is for; Bolton's site has linked this domain from its sidebar for over a decade. Jerry Weinberg, Perfect Software and Other Illusions About Testing, is short and permanently relevant on what management misunderstands about testing. Elisabeth Hendrickson, Explore It!, is the practical manual for exploratory testing.
For agile teams. Lisa Crispin and Janet Gregory, Agile Testing and its sequel More Agile Testing, define the tester's role on cross-functional teams. Gojko Adzic, Specification by Example, is the reference for acceptance test driven development and living documentation; Adzic is associated with a guest editorial in issue 16 of the magazine. Johanna Rothman's writing on program management covers the multi-team ground of the old Knowledge Transfer tutorial.
For techniques. Lee Copeland, A Practitioner's Guide to Software Test Design, is the clearest book on the classical techniques (equivalence partitioning, boundary value analysis, decision tables, state transition). Glenford Myers, The Art of Software Testing, is the 1979 original that still frames black-box and white-box thinking. Gerard Meszaros, xUnit Test Patterns, is the reference on why automated tests rot and how to structure them so they do not. For security, the OWASP Testing Guide (free) and the OSSTMM from ISECOM (free) are the two methodologies worth knowing.
Communities. The Ministry of Testing runs the largest practitioner community and a long-running conference series; the Association for Software Testing is the non-profit behind the context-driven school; the ISTQB member boards run the national certification bodies and, in several countries, free evening meetups. Testing-focused podcasts and newsletters come and go quickly enough that recommending one here would date the page; the communities above maintain current lists.
Choosing between them by need. If you must write a test plan a customer will audit next month: ISO/IEC/IEEE 29119-3 for the contents, Black for the management around it. If you are a developer or new tester who has to test well by Friday: Kaner, Bach and Pettichord first, Hendrickson second. If your team has just gone cross-functional and the testers are idle for the first week of each sprint: Crispin and Gregory. If your acceptance tests are long, brittle and owned by nobody: Adzic on specifying with examples, then Meszaros on why automated tests rot. If you need to design tests for a rule with many inputs: Copeland, one chapter per technique. If you are asked to prove your test process is mature: the TMMi model document, free, then van Veenendaal. If a security assessor is coming: the OWASP Testing Guide for web applications and the OSSTMM for the operational scope. If your manager thinks testing can be finished: Weinberg, and give them the copy.
Standards worth reading, and which part. ISO/IEC/IEEE 29119 is five parts and a technical report, and nobody needs all of them. Part 1 (2022) is concepts and vocabulary; read it once. Part 2 (2021) is the test processes in three layers (organisational, management, dynamic) and is the part to cite when asked what a test process is. Part 3 (2021) is test documentation, the templates, and the part contracts name. Part 4 (2021) is test design techniques with coverage measures, the reference behind this site's technique guides. Part 5 (2016) is keyword-driven testing, of interest only if you build that kind of framework. Technical report 29119-11 (2020) is guidelines on testing AI-based systems, the closest thing to a standard for the Testing AI Systems hub. Outside 29119: ISO/IEC 25010 for the quality characteristics that performance and usability testing are measured against, and IEEE 1028 for reviews and inspections. All of these are paid documents; the ISTQB syllabi, the TMMi model, the OWASP guides and the OSSTMM are free.
Common questions
Where did the old recommendations page go?
This page replaces both recommendations.html and links.php from the original site. The old lists were the publisher's; this one is the current editor's and is revised when a title stops being worth the time.
Why no vendor documentation or tool guides?
This site does not carry vendor or product names in its guides so that the material stays true as tools change. Tool documentation is best read from the tool itself.
Which single book should a new tester read first?
Lessons Learned in Software Testing by Kaner, Bach and Pettichord. It is organized as short lessons and covers the whole job without assuming a process.
Which standard should I cite for test documentation?
ISO/IEC/IEEE 29119 part 3. It superseded IEEE 829, which older contracts still name; the mapping between them is straightforward.
Is this list connected to the magazine's original recommendations?
Only in purpose. The original list is not preserved in the link record, so this one was written from scratch for current practice.