QA习惯拿着事先准备好的检查单，对项目一条条做审核，发现问题开不符合报告，
敏捷测试就是在敏捷开发模式下对软件进行的测试，要求尽早测试、频繁测试，以及时提供反馈。为了快速响应、迭代上线，开发忽略了单元测试、测试忽略覆盖率，线上问题很多
QA并行的同时工作在多个迭代：要对当前迭代的故事进行验收测试、探索性测试，和开发人员结对实现测试自动化;同时和业务人员结对分析下一个迭代的故事，编写验收标准和测试用例。
敏捷QA是特殊的，主要体现在：
敏捷QA需要在参与的每个阶段提出自己的建议，而不是等到开发流程最后来对系统进行验证;不仅要验证开发设计是否满足需求，还要发现需求是否能真正体现业务价值，分析是否有不恰当或缺失的需求。比如说，敏捷QA在跟业务人员结对编写验收标准的时候发现故事分析过程中漏掉的需求，在跟开发人员结对过程中跟开发人员讨论某个测试放在哪层实现比较合理等。
发现风险，并将风险与团队及客户沟通。QA参与整个开发流程，对系统整体的认识和把握可以说是团队里边最全面的，因此也更容易看到系统存在的风险。
及时向团队提供关于产品质量的反馈，便于调整。在每个迭代结束时候，QA需要分析统计该迭代的缺陷，并结合自己通过测试对系统质量的了解，及时跟团队反馈，讨论分析质量下降的原因以尽快作出改进，或总结质量上升的经验，鼓励团队再接再厉。
在制定产品和版本的发布计划的时候，QA可以根据自己对产品质量的了解，从测试人员独有的视角提出一些关键的建议。
QA通过参与开发流程的每个阶段，能够协助团队从内部提升质量，让质量融入到产品开发中来。比如：在故事验收阶段对测试覆盖率的确认。
持续集成：持续集成（CI）是一项软件开发实践，其中团队的成员经常集成他们的工作，通常每人每天至少集成一次，每次集成通过自动化构建完成。利用持续集成可以让缺陷在引入的当天就被发现并解决，降低缺陷修改成本；将集成工作分散在平时，通过每天生成可部署的软件；避免产品最终集成时爆发大量问题。QA可以关注这些持续集成发现的问题分布情况、解决情况、构建周期，及时度量出相关数据。
看板：最便宜的敏捷工具，可实现价值流、可视化、拉动、限制在制品、找出瓶颈等多个作用。用户故事可以用看板，QA自己的任务同样可以用看板管起来，便于QA之间互相沟通、对齐信息。
自动化测试：持续集成的前提是有自动化测试用例，以及代码静态检查、代码行覆盖率、代码复杂度等各种工具，如果这些没做起来，只是持续构建，并没有太大意义。自动化测试属于防御性测试，把所有的质量风险用穷举法列出测试用例，然后测试用例提前写好，然后写代码帮你执行，预防缺陷的泄露。但是成本同样非常大，是否能推行起来，就看领导的魄力了。
每日晨会：每个团队每天大概花15-30分钟，回顾昨天做了什么、昨天有些什么问题、同时也会介绍每个人今天计划做些什么工作（特点：是站着开会）。一般主持人由敏捷团队的成员轮流担任，这个时候可以了解每天发生的问题。QA可以参加晨会，根据自己的观察提出问题。
结对编程：两位程序员在一台电脑前工作，一个负责敲入代码，而另外一个实时检视每一行敲入的代码；操作键盘和鼠标的程序员被称为“驾驶员”，负责实时评审和协助的程序员被称为“领航员”；领航员检视的同时还必须负责考虑下一步的工作方向，比如可能出现的问题以及改进等。有助于提升代码设计质量；研究表明结对生产率比两个单人总和低15%，但缺陷数少15%，考虑修改缺陷工作量和时间都比初始编程大几倍，所以结对编程总体效率更高，同时结对编程能够大幅促进团队能力提升和知识传播。不过这个实践也是最难推行的，往往只有进度不紧的时候才会尝试。
用户故事：用户故事是站在用户角度描述需求的一种方式；每个用户故事须有对应的验收测试用例；用户故事是分层分级的，在使用过程中逐步分解细化；典型的描述句式为：作为一个XXX客户角色，我需要XXX功能，带来XXX好处。用户故事的好处是：用户故事站在用户视角便于和客户交流，准确描述客户需求；用户故事可独立交付单元、规模小，适于迭代开发，以获得用户快速反馈；用户故事强调编写验收测试用例作为验收标准，能促使需求分析人员准确把握需求，牵引开发人员避免过度设计。QA可以引导项目团队如何编写用户故事、验收标准。
迭代回顾会议：在每轮迭代结束后举行的会议，目的是分享好的经验和发现改进点，促进团队不断进步。会议需要Team全员参加，气氛宽松自由，畅所欲言，头脑风暴发现问题，共同分析根因；会议关注重点是Team共同讨论优先级，将精力放在最需要的地方（关注几个改进就够了）；会议结论要跟踪闭环。QA同样可以参加回顾会议，引导团队如何召开，并跟踪改进事项。
敏捷模式下的质量管理更具有挑战性，但与传统瀑布模式相比，其在应对需求变化、提升产品质量、加快需求响应、缩短交付周期、提前暴露风险、及时激励员工以及平滑人力资源的使用等方面具有明显优势。敏捷的焦点在于交付有价值的软件，一直到客户满意为止。在这个“快鱼吃慢鱼”时代，要想交付好而快的产品，不防用敏捷模式试试。
么QA人员在敏捷开发中可以做什么？
协同确定质量下限
协同确定敏捷流程
敏捷开发并不代表着没有流程，只是将很多效益很小的环节变为面对面沟通，减少大量不必要的时间浪费。QA需要做的事情就是参与整个敏捷流程的制定，识别必要环节进行保留，保证过程质量
协同确定各环节输出标准
(1)敏捷开发可能会使产品人员去掉MRD文档，但是PRD文档是不可或缺的，对于PRD的输出还是要有一定标准，保证产品环节流入研发环节的质量
(2)敏捷开发提倡TDD、BDD等开发模式，目的就是因为开发人员更了解自己的代码，通过让开发人员自测的形式提高提测的质量，以达到适当减少集成测试时间的目的。通过对单元测试覆盖率、通过率等标准的制定，保证开发环节流入测试环节的质量
(3)测试人员作为产品的最终守护者，是面向用户前的最后一道质量防线，更要有严格的准出标准满足产品的合格。
(4)运维人员作为部署者，需要执行系统包的上架、数据库的割接等等事项，面向服务器的直接部署同样需要上线标准较少人员失误带来的部署问题
保证质量下限
对于制定的一些标准仍然需要监督遵守，毕竟人总是喜欢偷懒的，没有一段时间的监督是没办法让所有人自觉遵守的。所以QA要监督团队的质量下限遵守，让所有人慢慢养成习惯才可以
必要的时候QA需要充当Scrum Master的角色，参与敏捷流程各个环节引导团队成员正确前进，以达到提升质量的作用
发现风险，提出关键建议
QA参与整个开发流程，对系统整体的认识和把握可以说是团队里边最全面的。也更容易发现各个环节潜在存在的风险，提出并持续关注
参与整个开发流程，对于产品、开发、测试、运维环节的计划等，站在质量人员独有的视角提出一些关键的意见
传播质量文化，鼓励挑战质量上限
QA参与整个开发流程，不可必然的需要同每个环节的人员沟通交流，QA需要在这些交流中不断的传播质量文化
QA需要在传播质量文化的同时，也要鼓励团队人员挑战质量上线。
数据统计，持续改进
数据统计，这是QA必须掌握的一项技能。要主动寻找统计对象，通过不同的统计数据进行分析，发现敏捷开发、产品等等存在的问题
持续改进，将参与开发流程、数据统计发现的问题，组织进行持续的改进，让整体质量不断提
—
敏捷测试中测试人员需要做什么？
分析用户需求，代理PO(产品负责人)
在敏捷开发中PO责任重大，但是PO也会有繁忙、遗漏的时候，敏捷测试人员必要的时候要充当PO代理，帮助产品负责人补充、细化需求、完善用户故事等。
测试人员面向的对象是产品，想要真正保证产品的质量，对于需求的理解是最重要的。
不仅是编写测试用例，测试需求(定义质量)
敏捷测试不仅需要编写测试用例，还需要测试能否完整理解产品需求，根据产品需求转化为测试需求，根据产品需求点转为为测试点。
对于测试进行需求化管理，站在研发的角度转换测试需求，更利于业务需求的澄清，让开发、其他测试人员对于需求有更深入的了解。
同时测试需求的转化，也是对于质量的定义。在测试需求转化过程中必定会加入测试要求，这不就是对于需求质量的定义嘛
保持质量视角，参与过程评审
敏捷开发流程中会有一些必要环节的评审，例如需求评审、设计评审等等。作为敏捷测试人员不仅仅是要参与这些环节，而是要保持质量的视角发展问题，例如需求是否不闭环、概要设计是否不完善、需求是否不清晰、设计是否不可测等等。
与客户和开发者紧密合作
根据工作性质，作为团队第二位对需求最了解的人，测试人员需要定期或经常与客户（业务）沟通合作;并且作为需求二次转化者，你同样需要跟开发者紧密合作。
发布演示(UAT验收)等环节，建立了一条让测试人员与客户（业务）沟通合作的通道，要好好把握沟通渠道，直接的沟通可以让你对需求更加了解
测试需求的评审、开发过程需求的问题，都需要测试人员与开发者进行紧密的合作，让需求讨论、问题定位变得快速简单
提供快速反馈
敏捷开发提倡快速沟通反馈，对于测试人员也是一样的。快速反馈系统存在的问题，以便于图啊对快速做出应对。
例如重视冒烟测试，快速验证系统是否可执行，避免测试工作无法进行浪费时间;根据更为详细的测试需求，快速检查验证是否有开发遗漏，尽快进行补充;测试遇到的问题，快速反馈进行解决;测试进度快速反馈，提醒运维人员提前准备介入等等
用测试策略规范测试
前面对于敏捷开发中质量人员角色的定位，测试人员要保证质量下限。那什么方式可以让测试人员保证质量下限，人员素质是一个重要因素，但是你并不能保证所有测试人员的素质都可以快速提升，这个时候规范的测试流程就是最根本的保障。
测试策略是一个很大的课题，推荐阅读刘琛梅老师的《测试架构师修炼之道》，对于测试策略有较深入的讲解，我对于这本书也有进行过一次阅读分享
测试者和分析者角色融合
敏捷测试中需要测试人员将测试者与分析者融合，站在测试角度分析需求合理性、站在测试角度分析系统可测性等。
分析者习惯将问题解剖，而测试者会带着“挑剔”的眼光审视问题，两者的融合不就是将问题解剖发现内在的“缺陷”嘛
掌握探索测试(合适的探索性测试)
首先需要理解探索性测试，探索性测试简单理解就是在功能测试完成后，根据系统逻辑不断探索边界，逻辑的边界、部署环境的边界、系统的边界等等，去发现更多的问题。
合适的探索性测试，探索性测试并不是没有规律的盲测，它一样需要规律条件刘琛梅老师的《测试架构师修炼之道》也有提到这一点。
不要陷入探索性测试，你的底层基本功能都还没有测试完成就去探索，那将没有任何意义
自动化回归测试
敏捷开发提高的是效率，而对于测试人员而言一样的需要提高效率，将大批量的旧版本旧需求的回归自动化，不久节约了大量的时间可以用来进行新功能、新需求的探索性测试了吗？但是请记住敏捷开发中的自动化测试同样讲究的是效率。
而对于UI自动化，建议跟前端配合将页面元素id规范化，共同制定一套id规范才有利于UI自动化的维护，PO模式确实也是是很好的选择
相对于UI而言，接口可能更适合先进行自动化，同样可以借鉴UI的PO模式管理，减少维护成本