The aims of this book are to provide a brief introduction the the discipline of software testing, and to provide a handy reference for testing practitioners.
1. Certainly more useful for someone new to project management: Terms such as (test) stakeholders, (test) requirements with goals / scope / priorities, (test) acceptance criteria, (test) design, execution, schedule etc were introduced without great depth or breadth.
2. There is no focus on a particular domain or on a few exemplary domains, e.g., hardware or software systems or human activities, but "systems" in general, although the book lacks of any theory about systems
3. You won't find scientific references, e.g., empirical studies on errors
4. There's little or nothing on: ・testing-strategies ・error detection ・defect-analysis ・reporting / tracking ・testing-heuristics ・cognitive bias in testing ・testing-mistakes ・specific technologies (missing intentionally). E.g., bugs are not evenly distributed in a software system but form clusters, with likely 60% bugs in the top 20% of the largest subsystems. Biases of developers testing their own products (curse of knowledge, overconfidence, confirmation or congruence bias), membership bias, Hawthorne effect/social desirability bias, inattentional blindness, etc. Mistakes, like not testing the documentation or installation procedures or configurations; or checking that the product does what it's supposed to do, but not that it doesn't do what it isn't supposed to do. Nothing like that.
5. Apart from definining testing in and of itself, this book makes no attempt to put testing in perspective of the overall quality effort. Don't expect something on: ・Quality Assurance, ・Quality Planning ・long-term/cultural Quality Management approaches (Business quality → process quality → product quality). Testers may not decide about defect-prevention but defect-detection: Gerrard defines TESTING more abstract in terms of establishing evidence to inform confident decisions—testing is an information-business; not mere finding defects (QualityControl / pre-shipment inspection / afterthought, last defense), but also to check that a product addresses the stakeholder needs.
6. Gerrard assumes that you receive already well-formulated (quality) goals from the customer, but at least from a pedagogical point of view, I find it helpful to know (the vocabulary for) all the quality dimensions or attributes of a product or process. Most lists or Utility-trees on the web are incomplete and/or poorly structured—would have been an opportunity.
7. Paul Gerrard's pocketbook offers 104 pages, with ⅓ introducing or motivating the other two thirds. The last third repeats the previous one in a different way for reference sake (although already a pocket book). I found it somewhat redundant, so the latter pages could have been better used to cover some of my aforementioned points.
Overall: Okay from the managerial perspective, but rather useless for somebody who has to design and execute tests too. 4/5 stars at 0–2 EUR, and 3/5 stars at 7 EUR (8.66 USD)