老徐最开始接触敏捷测试，是在2013年。那时候，敏捷非常火，各大公司陆续引入敏捷实践。但，这些年过去了，落地的结果是，很多公司，还在玩伪敏捷 ，或者效率并不高。为了让更多同学，了解敏捷，先摘录几段敏捷的介绍：
“ 敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）”。
“ 敏捷测试是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程 ”。
“ 敏捷测试是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践 ”。
敏捷测试的一些特点：
1）敏捷测试，强调测试人员的个人技能，始终保持与客户 / 用户、其它成员（特别是业务人员、产品设计人员等）的紧密协作，建立良好的测试框架（特别是持续集成测试和自动化回归测试的基础设施）以适应需求的变化 。
2）测试驱动开发的思想是敏捷测试的核心，或者说，单元测试是敏捷测试的基础，如果没有足够的单元测试就无法应付将来需求的快速变化、也无法实现持续的交付（这也是很多团队，交付上线的产品，一堆质量问题）。
3）敏捷测试得基于一定自动化测试的基础，自动化测试在敏捷测试中占有较重地位。比如，互联网企业在1-3天内就有完成整个的验收测试（包括回归测试），甚至1天时间得交付。完全依赖手工不现实，且风险比较大 。
4）在敏捷测试中，可以由开发人员承担更多的测试自测工作，培养全员测试的习惯；质量是由整个团队的共同努力。
5）在敏捷测试中，甚至一些团队可以没有专职的测试人员，每个人都可以是测试人员，大家一起为质量负责 。
6）敏捷测试强调持续测试、持续的质量反馈 。
7）敏捷测试始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来 。
8）敏捷QA，通常会从需求分析阶段就开始参与整个软件开发过程，通过在不同阶段和团队中的不同角色合作，帮助整个团队对质量达成共识，并通过在不同阶段的确认和验证做到缺陷预防，而不是等到软件开发完成后再去发现缺陷 。
9）可以把常规的业务功能测试，交给开发人员自测；测试人员，重点关注，非功能性；比如，易用性、用户体验、业务流程，系统级测试 等。
10）在敏捷测试中更多时候我们会淡化角色的概念，强调团队人人都为质量负责，这样更有助于团队的每一位成员都把质量作为非常重要的一部分，而不是依赖于某个人或者某个角色。
敏捷测试的核心关键点 ：
1、多关注用户体验、系统使用场景，把单功能测试，交给开发自测 ；
2、测试尽早介入，参与项目全流程 ；
3、Code review、单元测试、自动化测试，非常重要；
4、持续集成、持续测试、随时随地测试，引入 CI / CD 。
“ 培养人才 / 招聘适合的人才 。”
总之 ，在尽可能短的时间内，尽快发现质量风险，通过一系列技术手段，快速交付，达到「质量 & 效率」的平衡 ；特别是在敏捷开发的团队，团队无法接受，一个版本，需要测试一周时间的。OK ，如上，敏捷测试，基础知识普及，概念介绍完毕（注：部分概念，引自网络） 。
回顾结合你现在每天在做的工作；多数互联网公司，都是在玩的敏捷模式；每天都在发版，使用迭代看板，每天都在上线。但，发版后，线上质量呢 ？
确实存在一些问题，也许是，敏捷这块，玩的不太对 。这里，涉及到对团队每个成员的能力要求非常高、对测试人员的能力要求非常高 ，很多测试人员的知识体系，还不足以支撑如上关于敏捷测试的10条原则 。也涉及到「测试左移、测试右移、持续测试的概念」。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
