书籍介绍
《敏捷软件测试:测试人员与敏捷团队的实践指南》内容简介：测试是敏捷开发的关键组成部分。敏捷方法的广泛应用使人们开始关注如何有效测试，同时敏捷项目改变了测试人员的角色。但是，测试人员的许多职责还是得到了不少误解，测试人员的真正职能是什么？敏捷团队真的需要具有QA背景的成员吗？“敏捷测试人员”到底意味着什么？
业界经验最丰富的两位敏捷测试实践者和顾问Lisa、Crispin和Janet Gregory在《敏捷软件测试:测试人员与敏捷团队的实践指南》中给出了这些问题和更多问题的答案。在《敏捷软件测试：测试人员与敏捷团队的实践指南》中，crispin和Gregorv定义了敏捷测试的概念，并通过来自现实敏捷团队的示例阐述测试人员的职责。她们讲述如何利用敏捷测试象限来识别需要哪些测试，谁来做，以及哪些工具有帮助。《敏捷软件测试:测试人员与敏捷团队的实践指南》从测试人员的角度记录了敏捷软件开发迭代的一个完整周期，并解释了敏捷测试的七大关键成功要素。
读者将从《敏捷软件测试:测试人员与敏捷团队的实践指南》中收获
测试人员如何参与敏捷开发
测试人员和QA经理如何适应敏捷团队
敏捷测试人员的招聘要求是什么
如何从传统模式迁移到敏捷模式
如何在短期迭代中完成测试任务
如何利用测试指导开发
如何克服困难实现测试自动化《敏捷软件测试:测试人员与敏捷团队的实践指南》是敏捷测试人员、敏捷团队及其经理和客户的必备书籍。
克里斯平（Lisa Crispin）是一名敏捷测试实践者和教练。她专注于向测试人员和敏捷团队讲述测试人员如何创造价值并利用面向业务测试指导开发。她的使命是把敏捷的快乐带给软件测试领域，并把测试的快乐带给敏捷开发领域。Lisa在2000年第一次加入敏捷团队，作为开发人员、分析人员、测试人员和质量保证主管工作了若干年。从2003年起，她成为ePlan Services公司ePlan Services团队的测试人员。她经常在北美和欧洲的会议上教授有关敏捷测试的课程。Lisa经常发表敏捷测试的文章，刊物包括Better Software magazine、IEEE Software和Methodsand Tools。Lisa与Tip House合著了Testing Extreme Programming（Addison-Wesley,2002）。
格...
AI导读
核心看点
- 本书系统阐述了敏捷测试的核心理念，明确测试人员在敏捷团队中的正确角色定位，强调测试应贯穿需求分析、编码及交付全过程，而非仅在开发完成后介入，旨在消除对测试职能的误解，促进团队整体质量意识的提升。
- 书中提出的‘敏捷测试象限’是极具价值的理论框架，将测试活动划分为支持团队与评价产品、面向技术与面向业务四个维度，帮助读者清晰识别不同场景下的测试需求、责任主体及工具选择，为构建全面的测试策略提供结构化指导。
- 详细记录了测试人员在敏捷迭代中的完整工作流，包括迭代前准备、需求澄清、测试用例设计、自动化策略制定及迭代收尾等环节，并结合大量真实案例，深入探讨如何克服文化阻力、迁移传统流程以及实现可持续的测试自动化。
适合谁读
- 从事软件测试工作的专业人员，特别是希望转型适应敏捷开发模式、提升在敏捷团队中协作能力与影响力的测试工程师，本书能提供从传统测试向敏捷测试思维转变的必要指导与合规建议。
- 敏捷开发团队中的开发人员、项目经理及技术负责人，通过阅读本书可理解测试在敏捷流程中的关键作用，学习如何与测试人员有效协作，共同构建高质量软件，避免将测试视为独立于开发之外的孤立环节。
- 正在经历或计划进行敏捷转型的企业管理者及QA经理，书中关于组织文化挑战、团队构成调整及传统过程迁移的章节，能为管理层提供识别转型障碍、优化资源配置及制定合理测试策略的管理视角。
读前提醒
- 本书中文译本被多位读者反馈存在翻译生硬、语句不通顺及术语理解困难的问题，严重影响阅读体验。建议读者在条件允许的情况下优先阅读英文原版，或结合其他优质中文敏捷测试资料辅助理解，切勿因译文问题否定原书价值。
- 书中包含大量作者的个人经历与冗长案例，部分读者认为内容啰嗦且架构松散。建议读者跳过繁琐的故事叙述，直接聚焦于‘敏捷测试象限’、‘自动化测试金字塔’及‘迭代工作流程’等核心章节，以获取实质性方法论。
- 本书出版较早，部分技术背景与当前微服务、云原生等现代架构存在脱节。读者应批判性吸收其测试理念与协作原则，而非照搬具体技术实现。对于自动化测试等章节，需结合当前主流工具链与最佳实践进行补充学习。
读者共识
- 尽管翻译质量普遍受到批评，但书中提出的‘敏捷测试象限’模型被公认为具有开创性价值，是理解敏捷测试分类与策略制定的重要基石，许多读者认为这一理论框架足以弥补其他方面的不足，值得深入研读。
- 读者普遍认为本书理论性强但实操性较弱，缺乏针对现代复杂架构的具体测试策略指导。书中内容较为浅显且重复啰嗦，不适合初学者作为入门教材，更适合作为有一定经验者梳理测试理念、纠正错误认知的参考读物。
- 多数读者指出书中关于测试人员角色转变、团队协作及质量内建的讨论具有启发性，有助于打破测试与开发的对立思维。但同时也警告，书中的部分咨询式套路和空洞理论需结合实际情况甄别，不可盲目套用。
本导读基于书籍简介、目录、原文摘录、短评和书评生成，不等同于全文精读。
精彩摘录
- " Agile Is All about Feedback"
- "Testers will conduct manual exploratory testing to find important bugs that defined test cases might miss. Testers might pair with other developers to automate and exe- cute test cases as coding on each story proceeds. Automated functional tests are added to the regression test suite. When tests dem"
- "As a (role), I want (function) so that (business value)."
- "Security Testing Perspectives 1. Adopt a continuous integration (CI) process that periodically runs a suite of automated tests against your application. 2. Learn how to use one or more open source static code analysis tools. Add a step to your CI process that consists of running these tools against "
- "Performance Testing from the Start Ken De Souza, a software developer/tester at NCR [2008], responded to a question on the agile-testing mailing list about when to do stress and perfor- mance testing in an agile project with an explanation of how he approaches performance testing. I'd suggest design"
- "Standards for developing the GUI also make the application more testable and maintainable, because testers know what to expect and don’t need to wonder whether a behavior is right or wrong. It also adds to testability if you are automating tests from the GUI. Simple standards such as, “Use names for"
- "After the product owner reads the story, the following discussion ensues: Product Owner: “We just want some easy way for users to delete items, but we don’t have a specific implementation in mind.” Tester: “Should they be able to delete several items at once?” Product Owner: “Oh, yes, just make it a"
- "Tester: “What are the shipping speeds the user can choose?” Product Owner: “Standard 5-day, 2-day, and next-day.” Programmer: “We should probably start by only offering one speed, and calculating that cost. Then we can easily implement the other two speeds.” Product Owner: “It’s fine to break it up "
作者简介
克里斯平（Lisa Crispin）是一名敏捷测试实践者和教练。她专注于向测试人员和敏捷团队讲述测试人员如何创造价值并利用面向业务测试指导开发。她的使命是把敏捷的快乐带给软件测试领域，并把测试的快乐带给敏捷开发领域。Lisa在2000年第一次加入敏捷团队，作为开发人员、分析人员、测试人员和质量保证主管工作了若干年。从2003年起，她成为ePlan Services公司ePlan Services团队的测试人员。她经常在北美和欧洲的会议上教授有关敏捷测试的课程。Lisa经常发表敏捷测试的文章，刊物包括Better Software magazine、IEEE Software和Methodsand Tools。Lisa与Tip House合著了Testing Extreme Programming（Addison-Wesley,2002）。
格雷戈里（Janet Gregory）是DragonFire公司（致力于敏捷质量过程咨询和培训）的创始人。她希望帮助团队构建质量系统。在过去十年间，她作为教练和测试人员，把敏捷实践介绍到各种规模的公司。她关注于让业务客户和测试人员理解其在敏捷项目中的角色。Janet的编程背景使她能更好地与敏捷团队中的开发人员合作以实施新颖的敏捷测试自动化方案。Janet经常在敏捷和测试软件会议上发表演讲，也是北美敏捷测试社区的主要贡献者。
目录
第Ⅰ部分 简介 第1章 敏捷测试的定义 1.1 敏捷价值 1.2 “敏捷测试”意味着什么 1.3 敏捷团队中角色和活动的情境 1.4 敏捷测试有何不同 1.5 整体团队运作方式 1.6 小结 第2章 敏捷测试人员的十条法则第Ⅱ部分 组织挑战 第3章 文化挑战 第4章 团队构成 第5章 迁移传统过程第Ⅲ部分 敏捷测试象限 第6章 测试的目的 第7章 支持团队的面向技术测试 第8章 支持团队的面向业务测试 第9章 面向业务测试工具包 第10章 评价产品的面向业务测试 第11章 利用面向技术的测试评价产品 第12章 测试象限总结第Ⅳ部分 自动化 第13章 自动化的原因和障碍 第14章 敏捷测试自动化策略第Ⅴ部分 测试人员经历的一个迭代 第15章 测试人员在发布或主题 第16章 迭代前的准备 第17章 迭代开始 第18章 编码和测试 第19章 迭代结束时的收尾工作 第20章 成功的交付第Ⅵ部分 总结 第21章 关键成功要素术语表参考文献
用户评论
里面提出的四象限测试分类图是此书最具价值的地方。
书太浅了而且架构不够清晰，中间穿插的故事太繁琐，可读性不强
写的很细，结果很啰嗦。有的地方觉得写的泛泛，不接地气
作为程序员，这本书稍有看头的是第III部分和第IV部分。测试四象限，测试金字塔，自动化的ROI。
思路可以借鉴，内容有点无聊。
怎么说呢，不能说不对，但操作性不强。放在如今微服务盛行的时代，一定程度上缺了对新架构的测试策略适配。
外行人看热闹
提供了不少方法论，Agile Test的开山之作
我觉得还行 能总结东西就好
敏捷开发大潮下，测试团队如何跟上步伐，不拖快速迭代的后腿？测试人员观念上如何从瀑布式转型到敏捷式？方法论和价值观都不过时，对于测试团队，尤其测试主管有很好借鉴作用！作者条例非常清晰，也容易理解，书比较厚，如果没有事件可以看最后一章，总结基本上点到要点，不懂再回去看相应章节。
没有什么干货，全是理论。清华大学出分这本书买亏了。
清华大学出版社的其他书籍查看全部
收藏