最近在看 Craig Larman和Bas Vodde写的 Practices for Scaling Lean & Agile Development 这本书，感觉作者挺重视“测试”的。多数敏捷开发类图书很少单独去谈测试，敏捷宣言和敏捷开发原则中也几乎没有谈到测试，而本书的作者在讲产品管理、计划、需求与PBI、设计与架构...之前就专门用一章的篇幅先谈“测试”，而且有50页的内容，超过其它十四章各个主题。作者叙述这章的方式也特别，用：
“尝试”做什么
“避免”做什么
来表达作者的观点、所提倡的测试方式、方法和具体的实践，这些也来自于他们多年（敏捷咨询项目的）实践经验。
这里把他们50页的内容浓缩为一张表，左边是尽量避免的项，右边是尽量尝试去做的项，供大家思考，看看是否对大家有启发？你们也可以对照自己公司的做法，在下面留言，谈谈你们自己的想法。
（讽刺的是：一方面他反对certified tester，但自己却被Certified LeSS）
这张表包括三部分：总体上测试的思考、面向用户的测试（褐色内容）、开发者测试（蓝色内容）。
注1: 绝不容忍Open的缺陷是指：找到一个缺陷就会尽快修复，其好处就是防止：
在跟踪许多bug上花费精力
花费精力在优先级排序上
延迟学到当修复缺陷时产生的知识
花费额外的时间修复Bug，因为开发人员不再记得代码
注2: 项目测试的臭味
多故障的测试
开发人员不编写测试
测试高维护
产品多故障
注3:关于测试的假定
测试必须是独立进行的，因此要与开发相分离
必须有单独的测试部门
必须有测试经理
测试必须由“测试人员”完成
测试不可以在代码完成前开始
测试必须在最末尾进行
测试必须是“计划周详的”
必须有“测试策略”和一个“主测试计划”
测试遵循以下顺序：I）测试用例设计，2）测试用例执行，3）测试用例汇报（一个测试瀑布流程）
百分百测试覆盖率太昂贵。
百分百自动测试太昂贵。
测试需要精密的测试管理工具。
注4:典型的研讨会日程：
PO介绍研讨会目的
Team和PO选择要工作的条目
PO对选取的需求做概述发言
发散：分局成几个子团体，就某个item讨论，写case
聚合大家的成果
重复“发散-聚合”几次
结论
提取
