在敏捷开发红遍大江南北的同时，敏捷测试的相关讨论而相对逊色很多。对于敏捷测试，大多数人都存在这样或那样的疑问，”什么是敏捷测试?”，”敏捷测试中，测试人员做什么?”， 在揭开这个谜题之前，我们还是先了解一下敏捷宣言吧。

　　个体与交互 重于 过程和工具

　　可用的软件 重于 完备的文档

　　客户协作 重于 合同谈判

　　响应变化 重于 遵循计划

　　敏捷测试继承了上述的敏捷宣言和其准则，而且，在关于敏捷测试早的PPT中，定义了敏捷测试的两个主要特点:遵循敏捷宣言的测试实践，将开发当成是测试的客户”(Testing practice that follows the agile manifesto， treating development as the customer of testing)，以及“在使用敏捷技术的项目中的测试实践”(Testing practice for projects using agile methodologies)。

　　What is it?

　　那么到底什么是敏捷测试呢?这里的确很难给出一个明确的定义，但是可以借鉴一下网络上流传的一种定义，”在敏捷开发的软件过程中的测试是敏捷测试”。而且，敏捷测试更多的是一种理念，而不是一种过程。对敏捷测试的理解不能与传统的测试流程相混淆。

　　实行敏捷测试的过程不是一个独立的过程，它应该是和开发紧密相连的，在产品的生命周期中，处处都应该存在它的影子。所以，敏捷测试应该是一个integration的任务，在不同的层面(UNIT Test，function test，E2E…)，都需要按照敏捷的方式组织测试，目的是符合敏捷测试方法的价值观。至于敏捷测试这个敏捷开发的同源产物，自然也会继承其中的“目标驱动”而不是“过程驱动”的特性。

　　敏捷测试与传统测试的不同点在于:

　　敏捷测试并不倾向于严格区分开发和测试角色，全体工程师对于质量具有同等的责任，测试任务由开发和测试工程师共同完成，只是侧重点不一样;

　　敏捷测试的迭代周期很短，为了在很短的迭代周期中完成测试任务，要求建立“足够好”的验收测试，建立足够的自动化测试;

　　敏捷测试不严格依赖于文档(需求，设计等)，测试角色必须和其他成员以及客户有良好的沟通，以保证建立的质量标准符合用户的需求，以及能够使用项目中的相关知识建立合理的测试框架;

　　关于底层测试和关于代码质量是敏捷测试中的一个非常好的实践。

　　How We Do it?

　　实际上，敏捷过程中与测试相关的任务很多，概括说来有如下一些：

　　建立不同级别的测试验收标准，包括单元测试、集成测试、系统测试等各个层面的验收标准;

　　推动整个团队的质量文化，保证整个团队的成员在质量责任与目标方面达成一致;

　　通过技术或是管理的手段，保证产品、代码具有良好的可测试性;

　　通过自动化测试手段缩短每个产品发布周期中测试所需的时间;

　　确认出可接受的软件质量标准，并建立针对此标准的验收测试;

　　深入了解应用系统和业务需求，通过探索性测试方法设计有效的测试用例，发现产品中的缺陷;

　　建立对整个团队可见的质量度量体系，保证整个团队能够随时看到产品的质量度量值。

　　鉴于，我们当前的项目比较大，而且要求公司全面做出改动是没有希望的，但是我们可以改变我们平时工作中的一些理念，让测试工作开展起来更具有效力。

　　1. Conversational Tests Creation

　　测试活动不仅仅只是测试人员的事情，我们需要与dev，pm多沟通，多交流，这样可以减少文档更新不及时造成的信息不匹配等问题。