敏捷测试的理解

       究竟什么是敏捷测试？在我个人看来，敏捷测试是一种注重“以人为本”，快速迭代的开发方式。因为人是一个项目中的关键所在，故以人为本；快速迭代，即我们进行短周期的开发，上线，反馈，优化，使得项目易于调整，故而敏捷。

敏捷宣言

      提到敏捷测试，不得不提到敏捷宣言。我们常常谈到的是其四个核心及12条原则。这里给出的是最原始的敏捷宣言，12条原则是对这四项核心内容的具体解释。我们用度娘也可以很方便的找到这12条原则。但是不妨我们来自己思考一下下面这几句话。

Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

      首先，人与人之间的交互优于流程和工具的，呼应了敏捷测试中的以人为本，工具固然重要，就像打游戏里的辅助，打的再好，也需要有输出；工具再好用，也需要有沟通。

      其次，可工作的软件优于完备的文档。我们在进行一个项目开发过程中，注重其产出，我们用“产品”去说话而不是详尽的文档，我们的客户也倾向于用最简单，最快速的方式去掌握产品的功能。毕竟，对于一个新鲜事物，我们倾向于去看演示，而不是研究厚厚的文档，也许我们掌握了其表层之后，会再去看那详尽的文档，所以，comprehensive documentation也是不可或缺的。

      然后，客户合作优于合同谈判。敏捷开发要求我们是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。而不是在合同谈判期间把功能锁死，敏捷过程利用变化来为客户创造竞争优势。我们让客户看到价值，满足了其需求，获得其肯定，那效果肯定不亚于一份合同的谈判。也许会给我们带来更多的“合同”。其实这里也间接的体现了以人为本。

      最后，响应变化优于遵循计划。因为敏捷开发提倡快速迭代，使得每一版本的规模比较小，所以更加灵活，可以在开发的各个阶段比较容易的实现客户的需求。计划还是要有，但是不需要完全按部就班，要随机应变，来达到尽早的、持续的交付有价值的软件来使客户满意这一目标。

敏捷测试与传统测试的区别

       其实前面说了这么多，大家肯定也对敏捷测试有了自己的理解。对比它和传统测试的区别，总结下来主要有这样几个：

1.在传统开发模式中，开发人员和测试人员各自独立。开发人员了解到产品需求后开始开发，测试人员拿到产品需求说明书后开始编写测试用例，等到项目结束，测试开始对照测试用例进行测试工作。在敏捷开发模式种，人人都是测试人员，对自己的业务负责，是一种边开发边测试的模式。

2.在传统开发模式的周期比较长，一般几个月到一年，敏捷开发模式的周期比较短，一般1~4周。响应其快速迭代的特点。

3.敏捷测试中强调测试自动化，没有自动化，也就谈不上敏捷。

---

敏捷给我们带来了什么

       自己也是刚刚加入一个新起步的敏捷团队，至于敏捷到底能够带给我们什么，我想应该有下面几点。

1.敏捷开发有益于个人发展。在一个敏捷团队中，我们督促自己进步，勇于接收新的挑战，用更多的知识去充实自己然后尽量去帮助别人。比如现在写这篇文章，就是自己在接收到新的知识之后，通过各种途径去把他传播给更多的人。在团队的内部，我们了解到了任何有用的知识，都会积极分享，互相学习。

2.敏捷开发培养个人的协作能力。敏捷开发更加侧重以人为本，发挥人的积极性，以此提高团队的工作效率。作为团队的一份子，无论是测试、开发人员，还是设计人员，他们都将为团队成败担当不可或缺的责任，是高度协作的团队。在这样的团队中工作，个人的协作能力会有很大的提高。

3.敏捷开发锻炼了个人沟通能力。前面处处提到人与人沟通的重要性，在这样的团队中当然更能提高我们的沟通能力，这是显而易见的。

       第一次在这种公众平台上写文章，不足之处还希望大家多多指正。