Lisa Crispin 和 Janet Gregory 两位女作者分别写了两本关于敏捷测试的图书，即 Agile Testing: A Practical Guide for Testers and Agile Teams（2009 年元月出版，后面简称为《敏捷软件测试》），More Agile Testing: Learning Journeys for the Whole Team（2014 年 10 月出版，后面简称为《深入敏捷测试》）。图 1 是这两本书的中文译本。
图1 敏捷测试仅有的两本图书
这两本书得到了不少赞誉，《敏捷软件测试》有 Bob Martin 大叔、极限编程掌门人并签署敏捷宣言的 Ron Jeffries 等名人推荐；《深入敏捷测试》有《拥抱革命》作者 Linda Rising、《敏捷武士》作者 Jonathan 等 11 位推荐者推荐，这里省去了赞美本书的文字，若有空可以看看原书中的“本书赞誉”。
缺乏简洁明了的敏捷测试定义
说这两本书误导我们，不局限于朱少民于 2017 年写的一篇文章——“你被‘敏捷测试四象限’蒙蔽多少年了？”，文中指出 2009 年出版的《敏捷软件测试》图书中把一个“通用的自动化测试策略”看作是“敏捷测试四象限”，而这四象限并没有体现出敏捷测试的什么特点，也没有体现出敏捷的价值观或思维方式，而不少读者却被蒙蔽了整整八年。实际上还有不少的地方有问题，但最显著的问题是作者自己都没想清楚什么是敏捷测试，这是有据可查的，说起这个证据，确实来得特别。
敏捷联盟（Agile Alliance） 官方网站上的“敏捷实践编年史”，其最后记录的事件是 “敏捷测试的定义发生在 2017 年”，如图 2 所示，而这个定义正好也出自这两本书的作者 Janet 和 Lisa。顿时就感觉很奇怪：《敏捷软件测试》（英文版）于 2009 年出版、第 2 本《深入敏捷测试》（英文版）于 2014 年出版，但为什么这个定义却发生在 2017 年呢？比第 1 本书的出版时间整整晚了八年，比第 2 本书的出版时间晚了三年。图书都已写了两本了，难道当时还没给出“敏捷测试”的定义？
图2 敏捷联盟 “敏捷实践编年史”最后两条记录
继续追寻下去，点开敏捷联盟 “敏捷实践编年史”（图2）上的链接“definition of Agile Testing（敏捷测试之定义）”，发现了一个有趣的故事，如图 3 所示。Janet 培训课的一名学生要求她为“敏捷测试”给出简洁明了的定义，即使他已经听了 Janet 为期 3 天的培训课程，但还不清楚敏捷测试的定义是什么。Janet 也去翻了自己和 Lisa 合写的那两本书《敏捷软件测试》《深入敏捷测试》，在书中也没发现有关“敏捷测试”明确的定义。随后，她找了最近写的博客，其中有一篇“敏捷测试不是方法论”，还到 LinkedIn 和 Yahoo 相关的敏捷测试群（组）里征求大家的意见，之后才有了“敏捷测试”的定义。虽然 2017 年给出的敏捷测试定义还不错，强调协作测试、缺陷预防，但她们俩早已出版了两本书。
图3 来自 agiletester.ca/definition-agile-testing 的截图
客观评价《敏捷软件测试》
为了更客观地写好本讲内容，资深测试同仁评价《敏捷软件测试》这本书，他的回答是：看完后介于“好像看不懂”和“似乎能看懂”之间，说这精辟的评论来自豆瓣。《敏捷软件测试》在豆瓣上的得分是 7.4，还算是不错的评价。这一讲并不是要贬低这本书，书中的确有值得读的内容，如 Bob 大叔对此书的评价是：“实用、智慧、反对教条”。只不过它没有把“敏捷测试”的定义讲清楚，读者看了这本书会有启发，但还是不知道如何去做。
朱少民摘录了几条豆瓣上的评论，仅供参考，有关更多的评论，你也可以到豆瓣上查阅。
- 讲得有点抽象
- 絮絮叨叨的例子，看得好晕
- 没有什么干货，全是理论
- 言语空洞，没有启发性的内容
- 写的很细，结果很啰嗦，有的地方觉得写的泛泛，不接地气
- ……
为了客观起见，摘录出两条五星的评论，一条评论是“里面提出的四象限测试分类图是此书最具价值的地方”，另一条评论是“测试四象限和投资回报率，是读完本书最有感觉的 2 个 idea”。而其中最闪亮的点“测试四象限”却又是我写的那篇文章“你被‘敏捷测试四象限’蒙蔽多少年了？”所批评的，“测试四象限”对测试是很有价值，但和敏捷没有太多关系，并且，测试四象限是由 Brian Marick 在 2003 年首次提出来的（出自他的文章“My agile testing project”），Lisa 她们做了补充。
《敏捷软件测试》结构与内容
为了让你更全面地了解这两本书的结构与内容，朱少民做了思维导图，如图 4 所示。
图4 《敏捷软件测试》全书内容的思维导图
先看第 1 本《敏捷软件测试》，由于空间有限无法完全展开，从整体结构上来看，基本合理，内容丰富：一开始也有敏捷测试的定义、敏捷测试人员的十条法则（但是有问题，后面会讨论）；第 2 部分讨论组织挑战，也没错，人是决定的因素，首先需要建立起敏捷文化；第 3 部分是本书的核心和亮点，即敏捷测试四象限；第 4 部分是自动化测试，在敏捷中很重要，但写得非常不够；第 5 部分也是本书的核心，即测试人员经历的一个完整的迭代；第 6 部分是总结。
《敏捷软件测试》中存在的问题
我们再看看本书是如何定义敏捷测试的，为此展开第 1 章的内容，总共有 5 小节，如图 5 所示。第 1.1 小节介绍了著名的敏捷宣言。
图5 《敏捷软件测试》第 1 章的内容
重点看第 1.2 小节是如何定义“敏捷测试”的，这小节一开始讨论了敏捷团队的主要角色——“程序员（以区分开发人员，开发人员是研发团队的所有人员）”和“测试人员”，而且说“敏捷测试人员的工作是保证团队交付客户需要的质量”，这明显是错误的，在敏捷中一致认可是团队对质量负责、对测试负责；这一小节也谈到了 TDD——测试驱动开发，这样的单元测试自然是程序员去做，作者还特别声明：本书不是有关单元测试的，而且本书提到“敏捷测试”时，通常是指面向业务的测试。
因此，《敏捷软件测试》这本书讨论的“敏捷测试”是：
-
测试人员所做的测试，如第 5 部分讨论的是“测试人员经历一个完整的迭代”，而不是谈一个迭代中的测试活动；
-
面向业务的测试，指系统级别的功能 / 非功能性测试。
所以《敏捷软件测试》这本书的基础就很有问题。因为敏捷更强调开发与测试的协作与融合，虽然可以有专职的测试人员，但也可以完全没有专职的测试人员，不能将敏捷测试局限于测试人员所做的测试。其次，敏捷测试也不能局限于系统级别的测试，如果比较传统测试和敏捷测试，系统级别测试是有区别，但区别小，而更大的区别是单元测试，单元测试是基础。没有良好的单元测试，整个研发会越来越慢，设计 / 代码重构风险也很大。最后，作者把测试局限于动态测试，需求评审、设计评审和代码评审等静态测试不见了。敏捷测试崇尚测试左移，不仅让开发人员做更多的单元测试和集成测试，而且整个团队也要做更多的静态测试。
第 2 章谈到了敏捷测试人员十条法则，其中和本专栏第 1 讲中谈到的 8 条敏捷测试原则相同或相似的有：提供持续反馈、简单化、持续改进、响应变化等，但我的原则更具体；不同的有：为客户创造价值、促进面对面的沟通、勇气、自我组织、关注人、享受乐趣。“为客户创造价值”没错，和本专栏第 3 讲的用户思维是一致的，而沟通、勇气、自我组织、关注人、享受乐趣都是敏捷团队共有的理念，并没有明确体现测试的原则。
第 5 部分，介绍从“计划、迭代前准备”一直到“成功交付”一个完整的迭代过程，如果这个过程交代清楚了，读者自然知道如何实施敏捷测试，就不会有本专栏的第 1 讲所讨论的失败案例。当时，他们测试团队是看过《敏捷软件测试》这本书的，如果还是不明白，就说明书中没交代清楚。不过，这本书的中文版翻译也非常糟糕，也是读者吐槽的重灾区之一。
《深入敏捷测试》内容和一些问题
再看看第 2 本书《深入敏捷测试》，内容更丰富了，思维导图如图 6 所示。虽然有些内容是上本书的导入，包括组织文化、角色和能力、技术债、自动化测试策略、探索式测试等，但这本书的确好多了，包括翻译。这本书对测试的实际工作更有帮助，或者说更接地气些，但也存在一些明显的问题，例如：
- “什么是敏捷测试”还是没有交待清楚。
- 组织文化不是和人、学习更紧密吗？为何不放在第 2 部分？不应该放在第一部分。
- 第 4 章是测试的思维技能，其实很糟糕，没有真正谈思维技能，只有一节讨论差异化思维。敏捷思维方式更没强调，系统性思维、批判性思维等技能也没触及。
- 为何会有“商业价值的测试”和“研究型测试”这样的分类呢？敏捷测试中所有的测试都不是为了客户的价值吗？
- 探索式测试是研究型测试吗？
- 第 13 章 其他类型的测试和敏捷测试没什么关系。
- 第 7 部分，环境是上下文，的确重要，但感觉是大杂烩，而不是真正考虑对敏捷测试影响大的上下文因素，例如，非关键性系统和关键性系统的敏捷测试有明显差异。
- ……
图6 《深入敏捷测试》全书内容的思维导图
两本书的内容很丰富，但由于篇幅极其有限，很难用一讲做全面地分析与讨论，只是希望能引起读者更多的思考，带着批判性思维去看一本书，自己的收获会更大。