敏捷开发大潮下，测试团队如何跟上步伐，不拖快速迭代的后腿？测试人员观念上如何从瀑布式转型到敏捷式？
作者是资深敏捷教练，方法论和价值观都不过时，对于测试团队，尤其测试主管有很好借鉴作用！本书框架条理清晰，容易理解。书比较厚，建议从事测试人员通读一遍，如果没有时间至少可以看下最后一章，总结基本上点到要点，不懂再回去看相应章节。
本书讲敏捷软件测试，我们团队测试既有软件对象也有一些硬件对象，结合测试团队实践，就本书来谈谈敏捷软硬件测试。
敏捷测试是敏捷文化下的测试实践，先来谈谈敏捷文化这个老生常谈的主题，团队成员先要理解敏捷并有共识才能在行动中贯彻下去，否则终归是水中月镜中花。
敏捷文化强调个体/人、交流、协作、可用性、响应变化，敏捷宣言中所强调的核心内容，都是与人有关，而实操中很多公司光有再造流程工具，依葫芦画瓢，唯皮相而已。
敏捷文化并不反对或更不彻底抛弃流程、工具、文档、计划等要素，只是敏捷文化更值得强调，文档之类都有成本，需要轻量化，不可成为敏捷阻塞点。
敏捷把过程进行了切分迭代，让产品进化过程看得见，一切为更有价值的输出及业务成长服务。我们常常把敏捷=更快，这也是敏捷生来就受到追捧原因之一，似乎实施了一套敏捷流程，产品就自然更快的交付到用户手中，成本就自然压缩了；或者认为更快=敏捷，那就可以让员工996就更快交付，就变通的敏捷了。当然，敏捷可能客观上促成了更快，但敏捷不是单纯追求更快，敏捷文化所谓价值导向，更重要的是更好。
测试是产品质量重要保证这一点在敏捷开发中依然成立，敏捷开发对测试提出了更高要求，无论是观念和技能都要求转型以匹配敏捷团队的要求，书中提到敏捷测试的十个法则，基本上就是敏捷实践的核心理念，值得强调的是：持续反馈，面对面沟通，持续改进，相应变化，自我组织。
测试敏捷化常常会掉入一些误区:
- QA或测试人员扮演“质量警察”的角色，测试人员很容易试图寻找最脆弱的环节，请抵制这种冲动，首先确保基本功能的正常工作，常用路径通过后再考虑其他情况，迭代进行。此外，记住协作是敏捷型团队灵魂，敏捷团队整体对质量负责，敌对必须杜绝；
- 敏捷切分后把sprint作为一个“小型瀑布”，敏捷测试人员应最早参与到迭代最初需求阶段，而不是在迭代编码后参与，这种方式很常常导致测试被压缩或落后一个sprint；
- 测试人员技能饱和固步自封，用例编写日渐成熟，黑白盒测试，冒烟测试，回归测试都会了，是不是就可以了，答案是否定的，敏捷测试倡导不断学习和自我组织，新的测试理念，测试框架，拓宽测试类型，性能、负载、压力、可伸缩性、安全性测试，测试数据的生成，测试环境的可靠性都是敏捷的基础，没有这些技能的铺垫，如何敏捷起来？ 这些技能的积累要求我们的测试团队是学习型团队。
- 书中强调了测试团队的独立性，测试团队独立于研发团队是没错，作者的出发点是测试团队与研发团队过于亲密，将导致测试人员像开发一样思考，丢失客户观点。而测试与研发向一个人汇报可能使所有交付代码的优先级大于交付已测试代码的优先级，这往往是产品质量败坏的开端，是非常糟糕的。 但这不意味着丢失敏捷的核心要义，那就是沟通、协作和快速响应，而不是扯皮、推诿、拖沓。 “敏捷开发一开始会使测试人员感受到挫败感，因为他们可能不能获得完整的需求文档或明确测试阶段或版本”，敏捷测试团队应克服不确定、乱序带来的不适感和挫败感，敏捷测试验收不再是发生在开发后独立的活动，而实穿插在整个迭代过程中并行开展（当然这包括了单元测试开始，单元测试本就是编码，xp下甚至强调TDD测试先行，确保代码高测试覆盖率、功能刚刚匹配要求、编码人员的质量意识，要我说TDD也是持续重构的前提）。当开发人员忙碌于故事的编码时，测试人员应开始编写详细用例了。
自动化是测试敏捷化的重要保证，由于学习曲线相对陡峭，测试团队对于自动化作用常常被低估或执行不够，如何做到快速响应，频繁持续反馈，唯有借助自动化手段，我们应该跳出原来觉得舒适的旧习惯，这些旧习惯不能让我们做的更好。 高占比的自动化测试，才能让团队有更多精力做一些探索性验收测试或非功能性测试来进一步提升产品质量
测试自动化程度可以用一个金字塔来描述，底部是单元/组件测试，中部是API测试，顶部是GUI测试，顶尖之外是少量的手工测试， 单元测试和API测试是ROI比较高的，而GUI展现层元素的变化都可能导致GUI自动化的失败，ROI相对比较低，这如同“3只小猪”的故事，底部相当于砖块房子，中间是木棍房子，上层是稻草房子，如果大部分用稻草构成，必定一吹就倒，基础必须坚实才能阻止大灰狼入侵。 “无论在什么地方，只要大多数人不愿意接受自动化，那就是自动化起始之地”
金字塔理论说明作者对GUI测试自动化是谨慎的，后面甚至提出“GUI无需测试，把精力放在单元测试、集成测试、API测试上”的观点，这一点值得商榷，作者成书在2010年，GUI自动化尚不是非常成熟导致GUI脚本编写和维护成本非常高，比如早期的基于X-Y位置录制；而近10年以来，GUI测试的框架已有大幅度的发展，watir、selenium等开源框架自动录制对元素的识别、参数化等能力的提升，GUI自动化编写重用性和可维护性大大提升，在此基础上自动化测试平台的定制化和GUI测试自动化是值得探索的。“测试自动化是团队工作的结晶，这句话怎么强调都不过分”，“无论大家说什么，请解决自己所遇到的问题”，花时间做正确的事，测试自动化就是正确的事之一。 “没有自动化任何测试团队会欠下很多技术债务”。
“所有的团队不论敏捷与否都在为需求斗争，传统瀑布型项目团队可能花数月收集需求却最终出错或延期。处于混乱模式下的团队可能根本没有需求，开发人员会猜测某项功能如何工作”，客户定义的故事不会提供太多的需求细节，如何确保我们真正理解这些故事。客户团队完成需求概要，确保开发人员和测试人员能够帮助客户把故事分解成合适的规模，并讨论故事的依赖性，小步快走给我们逐步纠偏创造了条件。
迭代回顾，测试团队同样需要回顾，看看“开始、停止、继续”清单，开始好的动作，继续成功的实践，停止负面行动，每天回顾直到形成习惯。
反馈时敏捷的核心价值，持续反馈帮助敏捷团队正常运转。“敏捷更快是因为反馈允许你找到并关注最有价值的功能”，“敏捷开发的价值不是更快，而是快速产生足够的价值帮助业务增长和成功，测试人员在提供反馈达到目标过程中扮演了关键角色”。
精心维护测试环境，“让你的测试环境尽可能于生产环境类似，使用反应现实世界的数据。要勤于重新构建一个生产环境类似的场景”。 ⭐️⭐️⭐️⭐️