敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力，是一种以人为核心、迭代、循序渐进的开发方法。传统的瀑布模型需要保证在项目开始的时候，所有的需求，至少是最主要的需求都是已知的，因此在从需求分析直到应用交付的过程中，能够基本保证需求的稳定性。不过这样理想的状况往往偏离现实，即便用户应用的场景并没有发生改变，但是需求的挖掘很少能够做到面面俱到的，疏漏总是难免，因此这样的情况下，完全、准确地捕获用户需求几乎是不可能的。响应变化不断演进，这就需要提出来新的方法论来适应变化，敏捷开发应运而生。
图1.敏捷软件开发流程
敏捷思想初起于九十年代中期。最早是为了与传统的瀑布软件开发模式相比较，所以当时的方法叫做轻量级方法。二十世纪初，17 位该方法的倡导者建立了敏捷联盟（Agile Alliance），并将该软件开发方法命名为敏捷软件开发过程。敏捷开发方法很多，比如极限编程、Scrum、特征驱动开发、测试驱动开发等等，这些方法各有其适应的场合，但是目前为止得到广泛应用的、也是用得最好的还是Scrum。
敏捷联盟在成立之初总结了四条基本的价值原则：
1.人员交流重于过程与工具
2.软件产品重于长篇大论
3.客户协作重于合同谈判
4.随机应变重于循规蹈矩
敏捷开发中的测试称为敏捷测试，敏捷测试依赖于团队的所有成员，所有人都要对项目质量负责。敏捷测试是以客户为中心、以结果为导向，勤于耕作、乐于学习、富有创造力，为客户创造商业价值。
成功敏捷测试的7个要素：
1.使用团队整体参与的方法：整个敏捷团队负责产品的测试和质量，强调从客户的角度，即从使用系统的用户角度，来测试系统。
2.采用敏捷测试思维：建议尽早开始测试，一旦系统某个层面可测，就要开始着手测试，同时随着测试深入，持续进行回归测试以保证之前测试过的内容正确。因此敏捷测试思维就是不断想办法来改进测试效率和效果，不断尝试各种方法满足测试需要。
3.自动化回归测试：为了提高回归测试的效率，测试人员可以选择自动化测试的方法进行回归测试。
4.提供和获得反馈：反馈是敏捷的核心价值，敏捷的短期迭代可以提供持续的反馈以帮助团队运转正常。
5.构建核心实践的基础：构建稳定的测试环境，测试人员需要清楚地知道环境信息以及环境部署版本等。
6.与客户协作：测试人员通过与客户协作，能够帮助客户理清需求，同时也能完整地理解用户故事。
7.保持大局观：测试人员要有大局观，从客户的角度看问题。
下面简略介绍敏捷开发团队中敏捷测试的具体实践。我们采用的仍是业界流行的Scrum作为具体的敏捷开发模式，Scrum 主要着重于项目管理，团队中的项目经理（Scrum master）需要在每个客户需求到来的时候制定 Sprint的周期，一般情况下每个sprint为两周～四周，定义每个 Sprint 的目标、分派任务、进行监督、最后总结得失并开始计划新的 Sprint。在迭代的 Sprint 周期中，开发部分负责编码、单元测试、重构和集成，测试团队负责系统测试、回归测试。
在每个 Sprint周期内，测试人员需要领取用户故事，与对应的开发人员形成紧密协作的工作小组。在需求阶段，测试人员首先需要完整地理解用户故事中所包含的业务内容，理清完整的业务逻辑，针对要测试的用户故事，尽早编写测试用例，必要的时候，测试人员需要与开发人员就测试内容进行一对一讨论，修正存在的错误。同时，测试人员需要针对用户故事进行测试数据准备，这部分测试数据需要及时与开发共享。对于当前Sprint所实现的系统功能，测试人员需要根据具体业务场景，验证已有系统是否满足需求定义，及时找出与需求不符的问题和缺陷，系统测试结果将成为重要的交付验收依据。
然而频繁的迭代工作，对于原有系统潜在破坏的可能性是极大的，这是敏捷开发方法固有的重大问题，因此测试人员需要对不断增加新需求的系统进行回归测试，以便确认新的代码和产生的新数据不会引发副作用，对于原系统的回归测试就成了必要的环节。针对回归测试的范围和强度，测试人员需要与需求人员、开发人员等团队人员深入讨论，相关的讨论结果不但作为本次迭代的回归范围，同时也将作为本类业务今后回归测试的基准。当系统需要持续迭代升级时，为了提高回归测试的效率，测试人员也可以选择自动化测试方法。
综上所述，敏捷测试即是快速响应并不断修正质量目标，正确建立测试策略，确认客户的有效需求能得以圆满实现。相信通过技术的不断探索前进，能够带动敏捷测试向更好的方向应用及发展。
