5 books every tester should read
QA as a profession has classic literature — every senior engineer knows it. If you haven’t read them yet, time to fix the gap. 5 books that shaped the modern approach to testing.
1. “The Art of Software Testing” — Glenford Myers
The 1979 classic, still being reprinted. Myers was the first to systematize what testing is and why it’s needed. The key idea — testing isn’t “prove it works”, it’s “prove it doesn’t work”. Find bugs, not confirm their absence.
What you’ll take away: test design fundamentals, equivalence classes, boundary values, cause-effect graphs. Many modern practices that seem “obvious” were first formalized here.
For: junior and middle. Seniors — for understanding the history of the discipline.
2. “Agile Testing: A Practical Guide” — Lisa Crispin & Janet Gregory
If you work in an Agile/Scrum team — must read. The book is about how testing fits into the modern iterative process: TDD, ATDD, BDD, the role of a tester in a cross-functional team.
What you’ll take away: agile testing quadrants (a 4-quadrant model for building test strategy), how a tester works with PM and developer, how to test in conditions of constant change.
For: middle/senior, team leads.
3. “Explore It!” — Elisabeth Hendrickson
A book about exploratory testing — the skill that separates a senior from a junior. How to find bugs that aren’t in test cases. How to structure “free” testing so it’s not “let’s tap buttons” but targeted hunting.
What you’ll take away: tour-based exploration, how to form hypotheses about bugs, how to document findings without the bureaucracy of test cases.
For: middle/senior. Especially those who feel that regression-by-checklist is their ceiling.
4. “Clean Code” — Robert C. Martin
Not a QA-specific book, but critical for anyone writing automated tests. If your tests are dirty — they become tech debt and block the team. Clean Code principles apply to Page Objects, test fixtures, helpers.
What you’ll take away: SRP, naming, function size, fighting duplication — all this matters in tests even more than in product code, because tests don’t have tests.
For: middle/senior automation engineers.
5. “How Google Tests Software” — James Whittaker
Internal Google view: how they test 1000 products with tens of billions of users. A 2012 book, but many principles (test infrastructure as a service, classification of tests by size S/M/L/E, Test Engineer vs SET) influenced the entire industry.
What you’ll take away: how testing scales, what to do when there are more bugs than time, how to organize the process in a large team.
For: middle/senior, team leads, anyone thinking about QA strategy.
What I’d do
✅ Don’t read everything at once. Take one book — read it in a month, try to apply at work. Then next one.
✅ Take notes. Not bookmarks. Bookmarks never get revisited. Capture ideas and quotes in Obsidian / Notion with a note about “why this matters”.
✅ Discuss with the team. After each book — one lunch & learn (30 min) where you share 3 main takeaways. The best way to retain.
Bonus — modern alternatives
The books above are the foundation. Fresher:
- “Continuous Delivery” (Humble & Farley) — for understanding where QA fits in modern CI/CD.
- “Software Engineering at Google” (free online) — the updated Google approach, including testing.
- “The Unicorn Project” (Gene Kim) — a DevOps novel, easy read, conveys the process intuitively.