敏捷软件开发是从1990年代开始逐渐引起广泛关注的一种新型软件开发方法，是能够应对快速变化的需求的一种软件开发能力，它作为一种新型的开发模式，被越来越多地应用到软件项目中。
　　敏捷软件测试指的是在敏捷软件开发过程中跟质量相关的一系列活动，和传统意义上的软件测试有很多区别，因为敏捷软件测试的概念一直比较模糊，所以经常会有人走入误区，我曾经在瀑布型的软件开发模式下做过几年的测试人员，所以在刚刚接触敏捷项目的时候也曾有过一些误解，但是在敏捷软件开发团队工作将近5年后，对很多问题有了新的认识，以下针对几个常见的误区和大家分享一下我的理解。
　　不需要测试策略
　　测试策略关注的是目标和方法，即怎样在限定的时间内有效利用有限的资源达到提前制定的目标，一般制定测试策略时会首先明确测试目标，然后确定需要哪些测试类型，各种测试类型所占的大概比例，选择测试框架，后规划一下软件发布前需要经历哪些测试阶段。
　　很多人认为，敏捷软件开发以用户故事为单元，是不是集中精力在用户故事测试足够了？是不是根本不需要考虑测试策略？
　　其实这是一个很大的误解，因为敏捷软件开发通常都是迭代式的发布，周期比较短，资源非常有限，这更需要我们统筹规划，小到一个用户故事，大到一个完整的用户特性，都需要考虑怎么合理利用测试资源，所以敏捷项目是非常需要测试策略的。
　　具体到实际项目中，通常团队会在项目初期（迭代0）制定测试策略，明确目标(包括功能性需求的目标以及非功能性需求的目标)，然后确定在开发阶段需要添加哪些自动化测试(包括单元测试，接口测试，契约测试，集成测试，系统级别的UI的用户场景测试)，并规定这些测试的大概比率(符合测试金字塔)，选择自动化测试框架（比如XUnit）以及需要哪些手动测试(包括探索性测试，可用性测试等)，还要规划每个发布周期需要进行的测试阶段（比如新功能测试，回归测试等），之后测试策略会对敏捷团队的开发及测试起到非常重要的指导作用，当然，每个团队因为项目的不同策略也会不同。
　　下图是一个简单的敏捷测试策略介绍:

　　不需要测试文档
　　测试文档通常包括测试计划，测试用例，测试报告，测试缺陷等文档以及相对应的可以指导测试的一部分需求文档。
　　很多人会认为，敏捷软件测试是不需要文档的，敏捷宣言中有一句“工作的软件 高于 详尽的文档”，尽管敏捷宣言后提到了“右项也有价值，我们更重视左项的价值”，但人们往往会忽视右项的内容，导致在很多刚开始实施敏捷开发的团队中完全否定了测试文档的作用。
　　首先不可否认，在实际的敏捷项目中，确实很少见传统意义上的正式的专门的需求文档和测试文档，但这并不代表敏捷项目没有文档，比如用户故事本身是需求的载体，用户故事中的验收条件是敏捷测试文档的一部分， 另外很多敏捷软件项目都会采用BDD的方式进行开发，将测试用例用业务人员能够看懂的自然语言描述，并结合自动化实现，形成一个融需求和测试为一体的文档，而且为了应对敏捷软件测试变化快文档更新不及时导致的问题，很多敏捷项目都在使用Living document。

　　纯自动化测试 or 纯手动测试
　　有些刚接触敏捷的人认为敏捷软件开发发布周期很短， 测试人员根本没有时间做手动测试， 所以应该采用纯自动化测试。
　　也有一些人认为，敏捷开发强调快速响应变化，如果投入成本在自动化测试上，那么肯定会导致维护自动化测试带来的资源浪费，所以应该采用纯手动测试。
　　这是两种极端的误解，虽然这两种观点所考虑到的难点确实存在， 因为在敏捷软件开发过程中， 迭代通常比较短，确实不会预留足够多的时间来做手动测试， 所以必须要有足够多的自动化测试来保障。
　　然而因为测试代码本身可能存在缺陷，而且有很多部分难以被自动化测试覆盖(比如界面的测试，可用性测试，探索性测试等)，所以敏捷测试也同样离不开手动测试。
　　至于关于自动化测试维护成本的顾虑，敏捷项目也确实存在变化比较多的特点，但通常变的都是比较接近用户的部分，所以应该尽量减少用户级别的依赖界面的自动化测试，而多增加一些不容易变化的底层的单元测试接口测试等。
　　推荐敏捷测试以自动化测试为主，手动测试为辅。

　　敏捷QA = 敏捷Tester
　　在很多刚接触敏捷实践的团队中，大家对敏捷QA的认识还停留在Tester的阶段，认为只要用户故事开发完成之后，QA去专职地做测试，发现缺陷够了。
　　这是一个很大的误解，首先QA(Quality Assurance/Analyst)，不是单纯意义的测试人员，通过这个角色的名称我们可以看的出来敏捷QA强调的是质量保障和分析，而不单纯是测试产品。
　　在实际的项目中，敏捷QA通常会从需求分析阶段开始参与整个软件开发过程，通过在不同阶段和团队中的不同角色合作，帮助整个团队对质量达成共识，并通过在不同阶段的确认和验证做到缺陷预防，而不是等到软件开发完成后再去发现缺陷，所以对于敏捷QA来说，其目标是软件开发完成后能够发现的缺陷越少越好，而对于Tester来说，发现越多的缺陷证明工作做得越。