《敏捷软件测试》读书笔记
关于本书将给你带来的收获：
- 测试人员如何参与敏捷开发
- 测试人员和QA经理如何适应敏捷团队
- 敏捷测试人员的招聘要求是什么
- 如何从传统模式迁移到敏捷模式
- 如何在短期迭代中完成测试任务
- 如何利用测试指导开发
- 如何克服困难实现测试自动化
敏捷团队vs传统团队
敏捷团队和传统团队不同，传统团队中每一个人只关注自己的本职工作，关注于保证在最终产品发布中发布所有确定的需求，因此照着文档进行项目开发。每个程序员更专注于代码的特定部分，测试人员通过研究需求文档来制定测试计划，然后等待测试工作就绪。这里开发团队更多的是作为一种执行机器。敏捷团队强调以团队的方式来解决问题，所有参与人员共同决定如何更好地改进产品，他们关注业务优先级，经常进行检查与调整，以交付具有业务价值的高质量产品作为目标。
敏捷团队中的测试人员
敏捷团队中的测试人员不是坐在那里等着工作降临，而是行动起来寻找在整个开发周期中都贡献价值的方式，思考如何帮助团队创造更多的业务价值。
在敏捷团队中，开发人员也会编写测试代码，那测试人员还需要做什么呢。
对客户来说，测试人员是构成客户团队不可缺少的成员，他们的特别之处在于既了解客户的观点，也了解技术实现的复杂性。他们可以帮助激发出更多的需求和示例，帮助客户以测试的形式表达需求，帮助客户描述在每个迭代中什么对他们而言是有价值的，并且编写测试来确保他们可以获得这些有价值的对象。测试人员从客户的利益出发来保证质量，识别产品在性能、稳定性或者安全方面的风险并与客户沟通。帮助客户团队针对迭代中的用例编写面向业务的测试，以确保测试通过和足够多的回归测试是自动执行的，并且尽可能让测试方法和工具简单。
对开发来说，测试人员协助开发团队交付最大的业务价值，与开发人员一起寻找测试中的遗漏。因为可以自动化测试单调、底层的边界条件测试用例，测试人员可以关注创造更大价值的领域，如探索性测试，可用性测试及用开发人员没有想到的方式测试应用。
敏捷测试人员的工作方式：在开始编码之前的几天或几小时编写反映每个故事需求的测试，而不是在还没有考虑写代码之前根据业务分析人员创建的文档准备测试。详细的功能测试用例在理想情况下是基于业务专家提供的实例的，它可以充实需求。测试人员通过执行手工探索测试来发现已有的测试用例可能遗漏的重要缺陷。测试人员可能与其他开发人员结对一起自动化并在每个故事的编码进行时执行测试用例。可以将自动化的功能测试添加到回归测试集中。当测试证明已经完成了最小功能，团队才可以认为故事完成。
由于测试人员乐于收集和分享信息，与客户或者产品负责人协作以帮助他们充分展示自己的需求，从而得到他们需要的功能，同时向所有人提供项目进展的反馈。
敏捷测试思想以客户为中心、注重结果、勤于耕作、协作、富有创造力、乐于学习和适时地创造业务价值。
敏捷团队中的协作方式
每一个项目、每一个团队、每一个迭代都是不相同的。团队如何解决问题依赖于问题本身，以及现有的人员和工具。作为敏捷团队的成员，需要适应团队的需求。
回顾：所有的团队成员都会参与回顾或其它过程来改进每个迭代或版本中可能存在的活动。整个团队将以头脑风暴的形式来解决问题并改进过程和实践。
反馈：敏捷项目中测试人员的最重要区别是快速从测试中得到反馈。它驱动项目前进，如果没有达到某些里程碑，那么也没有人来组织项目继续进行。
所有成员为质量负责：不单单是测试人员或质量保证团队为质量负责。整个团队经常共同思考如何设计具有可测试性的代码。
对测试人员的要求：乐于学习新技能和面对新挑战，不仅仅局限于测试问题；乐于承担任何任务或角色；重视客户和持续关注全局。
敏捷测试人员的十条法则
- 提供持续反馈——扫除项目阻碍和反馈项目进展
- 为客户创造价值——持续关注对客户最有价值的东西
- 进行面对面的沟通——帮助客户和开发人员达成共识
- 勇气——接受挑战，接受失败
- 简单化——帮助我们关注风险、投资回报和改善最痛苦的问题
- 持续改进——采取过程改进实践
- 响应变化——通过健壮的自动化测试适应需求的变化
- 自我组织——具有多重技能和多层次视角时团队自身能解决问题
- 关注人——敏捷团队成员互相尊重并且认可个人成就
- 享受乐趣——保持对工作的热情
转变到敏捷的挑战
当软件开发组织采用敏捷开发时，测试或质量保证团队通常需要花很长时间来完成转变。因为原有的文化已经根深蒂固，在转变时难免遇到困难，尤其是大家都习惯于现状。当尝试转变敏捷时，组织文化经常被遗忘，从而导致敏捷的失败。
首先要摒弃的是质量警察的思想，当质量团队热衷于保证质量、负责决定产品发布、强制程序员遵循代码标准时，这是和敏捷相违背的。测试人员需要从负责质量到参与到质量定义和维护的转变。
传统的测试团队习惯于在项目结束时快速、激烈地进行测试，而敏捷价值的中心思想是让大家时刻以最好的状态工作，团队以一致的速度工作，保持在这个确保高质量标准的速度。敏捷团队应该能够合理地评估在每个迭代中的工作量。如果在最后一天某些测试还没有完成，那么整个团队而不仅仅是测试人员都应该加班完成测试。
客户关系也是一个新挑战。传统的软件开发中，开发团队和客户之间的关系更像是买卖关系，而不是为了生产业务这一目标而共同奋斗的两个团队。在敏捷中，客户团队和开发团队的关系是合作关系，客户对敏捷项目的成功是至关重要的。他们对将要实现的功能确定优先级，并对项目的质量有最终的评判权。测试人员将于客户紧密合作来理解需求，并定义证明满足条件已经达到的验收测试。
团队应该能够自己解决自己的问题。敏捷团队最适合于自组织的团队。外在的强制容易受到团队成员的抵触，同时也不利于他们养成自发的质量意识。因此需要放手让团队成员有权决定自己的方式。
培训是一个容易被遗忘的环节，像其他学习如何在敏捷项目中工作的每个人一样，测试人员需要时间和培训。开发人员将获得结对编程、测试驱动开发和其他的敏捷实践培训，但是测试人员通常得不到任何培训。许多组织没有意识到也需要培训测试人员结对测试、处理不完整和变化的需求、自动化和需要的所有其他新技术。这会导致测试人员在进入敏捷团队后选择离开。
质量保证经理的职责
敏捷团队中，质量保证经理需要适应对项目进度的控制和缺少“过程”。
敏捷团队的经理让团队决定他们自己的技术和管理他们自己的工作量。不再由经历决定哪些已经完成了。团队决定交付成功应用需要的质量水平。经理确保提供必需的资源，确保每一个人都能学会如何高效率地工作。帮助测试人员克服他们在从确定的、顺序的测试阶段转移到快速迭代过程中的挫折，在快速迭代中，他们每天都可能执行完全不同的任务。帮助他们适应验收测试不再是发生在开发后的单独的活动，而是测试和编码整合的活动的观点。关注与清除障碍，让团队成员更出色地工作，而不是糟糕地管理团队的活动。
测试人员可以通过提供经历追踪进度和确定投资回报率需要的信息来帮助团队达到经历的期望。
敏捷测试人员的招聘要求
经历过失败后，Lisa的团队尝试用以下的条款招聘适合的敏捷测试人员。
招聘条件.png
这些需求带来了更适合敏捷测试工作的应聘者。追求职业发展和对敏捷开发显示出兴趣的测试人员更倾向于有正确的思想。团队需要对测试工具和自动化领域有较强能力的人，所以学习的热情是极为重要的。
如何让每个人保持活力并关注交付业务价值这个目标
度量和评定每个人的业绩有破坏团队协作的风险。每个人会忙于完成自己的绩效而忽略团队协作。如果团队在努力，管理层应该奖励促进团队交付业务价值的业绩，但不要惩罚个人。
在赋予团队权利自己发现并解决问题时，团队进展得最快。团队需要时间来学习如何分清问题的优先级并解决它们，团队犯几次错误是可以允许的。我们认为高效率的团队需要自己成长。必要时可能需要获得其他团队的帮助来帮助自己获得成功。
传统项目如何迁移到敏捷
在传统项目中有很多过程不能很好地迁移到敏捷模式，因为它们需要重量级的文档，或者是阶段性过程的固有部分、需要在每个阶段结束时执行退出手续。
度量标准
很多时候度量是为了得到数据而编写数据，但是它们是可以指导团队，帮助衡量进展的。要想办法减少测量的数量和寻找驱动正确行为的测量。基本的精简测量标准是“从概念到实现”所花费的时间，即从客户的功能需求到软件发布，关键在于团队持续、可靠地创造业务价值的能力。这能促使团队尝试不断地改进过程、缩短周期。涉及整个团队的测量比仅限于个别角色或者小组的测量更能驱动你迈向成功。把度量作为一种激励的手段而不是打击士气的方式，关注目标，而不是度量。当定义所需的度量时，应确保代价是合理的，要避免把更多时间花在评估任务和计算剩余时间上，而应该把时间用在更有生产力的活动上。
缺陷跟踪
缺陷跟踪系统减少了开发人员好测试人员之间的直接讨论。同时，需要花费大量时间将信息记录在缺陷跟踪系统。根据精简原则，我们应该想办法减少这种低效率。
最重要的是关注于改善沟通和促进协作。如果遇到了大量缺陷，应研究一下问题的原因。如果需要一个缺陷跟踪系统来做这件事，那就应该应用一个缺陷跟踪系统。如果用卡片可以帮助团队快速沟通和解决问题，那就用上各种卡片。如果测试人员向开发人员展示了一个由其代码引起的缺陷，并且编写了单元测试，缺陷立刻会被修补，那么就没有必要记录这个缺陷。
测试计划
传统的阶段性软件模式强调测试计划的重要性，其作为整个文档需求的组成部分。在敏捷项目中，团队不会依赖沉重的文档来通知测试人员该做什么工作。测试人员要与团队其他人员直接沟通，所以测试工作应通过任务卡的形式让其他人可见。
敏捷测试象限
敏捷测试象限.png
1、支持团队的测试
象限一：测试驱动开发
单元测试验证系统的一小部分的功能，例如一个对象或方法。组件测试验证系统的一大部分的行为，例如提供某些服务的一组类。所有这两类测试一般都使用测试自动化工具xUnit家族的一个成员进行自动化。首先编写测试的过程帮助程序员更好地设计代码。通过这些测试，程序员可以自信地编写代码来实现用户故事的功能，而不用担心对系统引入意外的改变。这些测试可以验证他们的设计和架构决定是恰当的。程序员测试通常是自动化过程的一部分，在每次代码导入的时候运行，即时地持续地向团队反馈内部质量。
象限二：面向业务的支持团队的测试
这些面向业务的测试也叫做面向客户的测试或者客户测试，它们确定外部质量和客户需要的功能。在敏捷开发中，这些测试来源于客户团队提供的实例。它们描述每个用户故事的细节。面向业务的测试在功能层运行，每个测试验证一个业务满足条件。大部分支持开发团队的面向业务的测试也需要自动化。在这两个象限中的测试的一个最重要的目的是快速提供信息并确保快速地解决问题。必须经常运行这些测试以给团队早期的反馈，防止对行为的未预料的改变。
象限一和象限二中自动化测试提供的快速反馈形成了敏捷团队的基础，这些测试在每次代码改变或者增加的时候运行。这些测试首先指导功能的开发，当自动化以后，它们提供了防止重构和引入新的代码的时候导致不希望的结果的安全网。这些测试帮助团队产生客户需要的业务价值。 它们验证业务逻辑和用户交互行为与客户提供的实例一致。
2、评价产品的测试
象限三：面向业务的评价产品的测试
象限三属于面向业务的测试，这些测试使用运行的软件来查看它是否没有达到期望或者能否对抗竞争。当通过面向业务的测试来评价产品时，要尽力模仿真正用户使用应用的方式。这是只有人类可以从事的手动测试。可能使用某些自动化脚本来帮助配置需要的数据，但是需要凭我们的感觉、我们的大脑和直觉来检查开发团队是否交付了客户需要的业务价值。
象限四：面向技术的评价产品的测试
象限四中的面向技术的测试的目的是评价产品的性能、健壮性和安全性等特性。如果我们在开始编码前知道对性能、安全、与其他系统的交互，以及其他的非功能属性的需求，那么很容易在设计和编码时留意这些。应该在开发周期的每一步都考虑评价产品的面向技术的测试，而不是留到最后。在许多情况下，这些测试甚至应该在功能测试前进行。
使用TDD可以针对代码是否满足每个功能需求给出快速反馈，但是单元测试并不测试非功能需求，例如容量、性能、可扩展性和可用性。当你的团队计划一个新的版本或者项目时，讨论需要来自于象限三和象限四的何种类型的测试，以及何时进行这些测试。不要把如负载或可用性测试等这些基本的活动留到最后，可能会太迟而不能修正这些问题。评价产品的测试中产生的信息应该反馈到矩阵的左边并应于创建新的测试来驱动下一步的开发。
确保已经覆盖了所有测试的checklist:
- 使用单元和组件测试能帮助我们应用正确的设计吗？
- 存在自动化的构建过程使自动化单元测试以提供快速反馈吗？
- 面向业务的测试能帮助我们产生符合客户期望的产品吗？
- 为期望的系统行为捕获正确的实例了吗？需要更多吗？以这些实例为测试的基础吗？
- 在开始编码前向用户展示和报告交互界面的原型了吗？用户可以把它们与完成的软件如何运行相联系吗？
- 为探索性测试预留足够的时间了吗？如何处理可用性测试？引入客户的程度足够吗？
- 在开发周期的充足考虑如性能和安全等技术需求了吗？有做非功能性测试的合适工具吗？
- 以矩阵指导开始。实验，并使用回顾以保持改进使用测试和通过测试了解的产品信息来指导开发。
自动化
敏捷的成功离不开自动化，通过持续构建来运行所有的单元测试和功能回归测试意味着测试人员能有更多的时间去做有趣的探索测试。如果没有实现自动化，测试团队会把时间浪费在冗长繁琐的手工测试上，将不能响应敏捷的快速变化和小步迭代。自动化帮助团队思考更优秀的设计，高效地发布高质量代码，将精力集中在如何提高业务价值上。同时因为有质量的快速反馈，团队可以轻松地对代码进行重构，减少技术债务。
敏捷自动化测试金字塔
自动化测试金字塔.png
敏捷测试自动化金字塔最低一层是基础，它主要由健壮的单元测试、组件测试和支持团队的面向技术的测试所构成，它们提供了快速的反馈，有最高的投入产出比。
金字塔中间一层包含了大多数用于支持团队的自动化业务测试，这些功能测试旨在验证我们在做正确的事情。该层次上的测试包括故事测试、验收测试、和比单元测试范围更广的功能测试。这些测试运行在API层或GUI之后，不通过GUI来直接测试功能。由于这些测试绕过了展现层，因此编写和维护的代价并不高。
金字塔顶层很少使用自动化，因为其测试的投入产出比最低。这些测试会使用并操作展现层，他们主要用于评判产品并成为回归测试的一部分。无论包含了多少自动化测试，大多数系统还是需要手工测试的，比如探索性测试和用户的验收测试等。
使用敏捷测试象限来辅助确定哪里需要测试自动化以及何时需要。测试自动化金字塔可以帮助团队在能够带来回报的测试自动化上作出正确的投资。
如何克服困难实现测试自动化
实现自动化并不容易，恐惧、缺少知识、以前使用自动化的负面经历、频繁改变的代码和遗留代码往往是自动化的障碍之一。在开始自动化之前，要综合考虑风险和投入产出比，什么时候需要自动化、从哪里开始自动化、用什么工具实现自动化、需要将哪些实现自动化，都是需要衡量的。
1、保持简单：保持测试设计简单、保持范围最小化，使用最简单的工具完成工作。
2、迭代式反馈：进行工具调研、使用、评估结果并根据需要尽快改变过程。
3、整体团队运作方式：以团队的名义意味着代码再设计时会更多地考虑到可测试性。同时团队成员联合起来可以汇集不同的视角和技能。
4、边做边学：问题越多，学的越多。
5、增量完成：先实现最基础最重要的功能，再一步步补充完善。
6、版本控制：与产品代码一样使用源码控制工具，测试资源与项目资源存储在同样的仓库中，使用相同的机制进行版本控制、标记并共享测试库
7、持续集成：如果没有将自动化测试脚本持续集成，团队将不能快速获得质量反馈，自动化测试也失去了一部分价值。
在实现自动化时需要注意一些事项，比如应确保自动化测试脚本是能在短时间内运行的，如果需要超过10分钟甚至需要几小时完成，那么就要考虑是哪部分的实现不合理，是否可以使用其它方式代替访问数据库。
敏捷关键成功要素
1、使用团队整体参与的方法
2、采用敏捷测试思维
3、自动化回归测试
4、提供并获取反馈
5、构建核心实践的基础
6、与客户合作
7、保持大局观
