敏捷旅程之敏捷测试
敏捷旅程之敏捷测试
敏捷测试是在敏捷开发中进行的测试，它充分接纳了敏捷或者XP的核心价值观：沟通、反馈、简单、勇气。简言之，敏捷测试思想是以客户为中心、面向结果的、技术性的、协作的、乐于学习的、勇于不断生产业务价值的。
传统的测试方法在敏捷实施中面临不少挑战。敏捷需要“快”，包括快速验证系统的能力、快速向开发提供反馈的能力；敏捷需要“多“，需要更多的沟通、需要更多的自动化测试；敏捷提供的东西“少”，缺少可以依赖的文档、缺乏”足够”的时间。无论是XP，Scrum，还是看板，都强调跨功能团队的组建、快速迭代、团队紧密合作、面向发布和可工作的软件。
换个角度，敏捷前的测试，开发团队和测试团队相对独立，开发团队开发完功能后交给测试团队，互相有不少交接标准，部门墙还是比较重的，尤其是涉及到利益比较大的时候。敏捷后的测试，开发和测试同在一个功能团队，以功能为导向，注重个体和交互，流程和工具也很重要，但持续不断地沟通，尽早反馈，简单快速，有勇气提出改变和尝试才是根基。
《敏捷软件测试》中列出的敏捷测试十条原则，以创造业务价值，主动提供技术价值（包括性能、稳定性、安全等）为己任，可以持续指导我们的工作：
1. 提供持续反馈（通过实例和测试描述用户故事，用户故事是在某种场景下发生的。运行可执行测试，得到有价值的反馈。通过回顾任务卡，得到任务评估中的差异，分析原因，争取下次做得更好。通过包含缺陷数目，功能覆盖率，剩余天数等趋势图，跟团队分享进展，对可能出现的问题提出自己的解决方案）
2. 为用户创造价值（敏捷测试人员需要总览全局，发布最重要功能，边边角角后面再来测试-关键路径要保证-核心功能不出错-常用路径正常，然后负面测试和边界测试，评估时保证迭代安排足够时间发布安全可靠的应用）
3.进行面对面沟通（三方协作－发挥产品、开发、测试的集体力量，从客户思考，同时也理解相关的技术局限和法律等局限，提供示例或者使用场景给到产品和客户，通过持续合作完成任务）
4.勇气（开发人员有勇气修改和重构代码，测试人员有勇气允许失败-短暂失败，吸取教训；有勇气允许他人犯错误，寻求帮助；在大家都很忙时，提出想法和存在的缺陷同样需要勇气）
5.简单（采用最简单的测试验证某项功能存在或者已经达到客户的质量标准，团队负责向客户团队提供信息并帮助他们全面考虑质量问题，最终决定由客户拍板）
6.持续改进（团队总是尝试更出色工作，在过程中的改进实践：总结回顾和使用阻碍代办事项等，一次只关注一到两个重要问题进行改进。通过寻找工具、技能、实践以帮助团队增加更多价值或更好投资回报）
7.响应变化（处理变化与团队成员同步，在预先解决方案和迭代从头开始之间找出平衡。团队一起适应变化，通过自动化测试完成主要功能的回归）
8.自我组织（多重技能和多层次视角关注任何测试问题，最高优先级的问题需要整个团队解决，立即讨论解决办法，团队自己创建方法并做出承诺最有效）
9.关注人（互相尊重并认可成就，有机会提高和发展他们的技能，以可持续步伐进行迭代，团队和个人互相需要，包括探索性测试技能，通过丰富产品知识进行全面的测试）
10.享受乐趣（所有团队协作，整个团队负责质量和测试，珍视测试人员的工作热情，一起享受成功的快乐）
敏捷测试四象限是敏捷测试理念的核心，覆盖使用工具支持手动、自动测试，支持团队角度、面向技术角度、面向业务角度、评价产品角度等。四个象限覆盖的内容其实蛮多的，里面的测试概念相信大家都听过，不少也实践过，怎样模式化形成系统的理论和知识技能，从而指导日常的团队测试建设，是需要细化落地的。
敏捷旅程之敏捷测试
象限一：支持开发团队，测试驱动开发（单元测试、组件测试）xUnit-开发人员测试，也是面向技术的测试，验证设计和架构，单元和组件测试使用与应用程序相同的语言，业务专家可直接阅读并理解代码，内部质量不是通过客户判断的，由程序员定义。
象限二：同样支持开发团队，但在更高层次上，面向业务测试（功能测试、实例、用户故事测试、原型、仿真等）－ 确定外部质量和客户需要的功能，也是测试驱动开发的一种，但层次更高，测试满足业务条件，可能与单元级别某些测试重复，但每个测试在功能层进行，每个测试验证一个业务满足预期中的条件，最终肯定也是调用底层的方法。大部分也需要自动化-快速提供信息快速解决问题，测试业务逻辑。
象限三：面向业务的测试（探索测试、场景、可用性测试、用户验收测试、alpha/beta），这些测试使用运行的软件来查看它是否没有达到期望或者能否对抗竞争，尽量模仿真正用户的使用方式-客户和用户执行，获取用户故事，可用性测试-焦点小组， 探索性测试通过策略和确定限制的动作来指导-使用创造性和直觉，基于测试结果进行不断探索。
象限四：面向技术的测试（性能和压力测试、安全性测试、非功能性测试），强调开始编码前对性能、安全、与其它系统的交互，尤其是非功能属性。应该在开发周期的每一步都考虑评价产品的面向技术的测试，而不是留到最后。在许多情况下，这些测试甚至该在功能测试前完成。
用回《敏捷软件测试》书中的话来做总结：每当遇到测试相关的困难时，整个团队应当一起选择或者开发相应的工具，一起解决问题；复杂的测试需要与常用业务工具结合，需要投入必要的时间构建适用于团队所有成员的合理测试架构；即使客户不在本地，也要想办法让他们参与到相应测试中；用一种能让所有利益相关者方便地了解迭代和项目进展的方式汇报测试结果；文档只需要记录有用的信息，适可而止，不能太重；在开发周期中应时常思考四个象限的测试；在测试中时刻总结经验教训，以便在后续的迭代中达到更好地驱动开发的目的。
