Agile 是一种迭代开发方法，开发和测试活动都是并发的.测试不是一个单独的阶段;编码和测试以交互方式和递增方式完成，从而产生高质量的最终产品，满足客户的要求.此外，持续集成可以早期删除缺陷，从而节省时间，精力和成本.
敏捷宣言由团队发布软件开发人员在2001年，突出了开发团队的重要性，适应不断变化的需求和客户参与.
敏捷宣言是&减去;
我们正在通过这样做并帮助其他人来实现软件开发的更好方法.通过这项工作，我们已经实现了价值和减去;
个人和流程与工具之间的互动.
通过综合文档处理软件.
合同谈判中的客户协作.
响应计划后的变更.
也就是说，虽然右边的项目有价值，但我们更重视左边的项目.
敏捷测试是一种遵循敏捷软件开发原则的软件测试实践.
敏捷测试涉及项目团队的所有成员，由测试人员提供的特殊专业知识.测试不是一个单独的阶段，而是与所有开发阶段交织在一起，例如需求，设计和编码以及测试用例生成.测试在开发生命周期中同时进行.
此外，测试人员与跨职能团队成员一起参与整个开发生命周期，测试人员对构建软件的贡献如下:客户需求，更好的设计和代码将成为可能.
敏捷测试涵盖了所有级别的测试和所有类型的测试.
在瀑布式开发方法中，开发生命周期活动分阶段进行.因此，测试是一个单独的阶段，只有在开发阶段完成后才会启动.
以下是敏捷测试与瀑布测试之间差异的亮点 :
| 敏捷测试 | 瀑布测试 |
|---|---|
| 测试不是一个单独的阶段，与开发同时发生. | 测试是一个单独的阶段.所有级别和类型的测试都可以在开发完成后开始. |
| 测试人员和开发人员一起工作. | 测试人员与开发人员分开工作. |
| 测试人员参与提出要求.这有助于将需求映射到现实场景中的行为，并构建验收标准.此外，逻辑验收测试用例将随需求一起准备好. | 测试人员可能不参与需求阶段. |
| 验收测试在每次迭代后完成并寻求客户反馈. | 验收测试仅在在项目结束时. |
| 每次迭代都完成自己的测试，因此每次新功能都可以实现回归测试或者逻辑被释放. | 回归测试只能在开发完成后才能实现. |
| 编码和测试之间没有时间延迟. | 编码和测试之间的通常时间延迟. |
| 重复测试级别的连续测试. | 测试是一个定时活动，测试级别不能重叠. |
| 测试经常被忽视. |
敏捷测试的原则是 :
测试推进项目 : 持续测试是确保持续进步的唯一方法.敏捷测试持续提供反馈，最终产品满足业务需求.
测试不是阶段 : 敏捷团队与开发团队一起测试，以确保在给定迭代期间实现的功能实际完成.测试不会在以后阶段进行.
每个人都测试 : 在敏捷测试中，包括分析师，开发人员和测试人员在内的整个团队都会测试应用程序.每次迭代后，甚至客户都会执行用户验收测试.
缩短反馈循环 : 在敏捷测试中，业务团队了解每次迭代的产品开发.他们参与每一次迭代.连续反馈缩短了反馈响应时间，因此修复它的成本较低.
保持代码清洁 : 缺陷在同一次迭代中被引发时是固定的.这确保了在开发的任何里程碑都能获得干净的代码.
轻量级文档 : 而不是全面的测试文档，敏捷测试人员&减去;
使用可重复使用的清单来建议测试.
关注测试的本质而不是偶然的细节.
使用轻量级文档样式/工具.
在章程中捕获测试想法以进行探索性测试.
将文档用于多种用途.
利用一个测试工件进行手动和自动测试 : 相同的测试脚本工件可用于手动测试，也可用作自动测试的输入.这消除了手动测试文档的要求，然后是等效的自动化测试脚本.
"完成完成"，而不仅仅是&减去;在敏捷中，一个功能据说不是在开发之后，而是在开发和测试之后完成的.
测试最后与测试驱动 : 测试用例与要求一起编写.因此，可以通过测试来推动开发.这种方法称为测试驱动开发(TDD)和验收测试驱动开发(ATDD).这与测试作为瀑布测试的最后阶段形成对比.
项目级别的敏捷测试活动是 :
发布计划(测试计划)
对于每次迭代，
迭代过程中的敏捷测试活动
回归测试
发布活动(测试相关)
迭代期间的敏捷测试活动包括 :
参与迭代计划
从测试角度估算任务
使用编写测试用例功能描述
单元测试
集成测试
功能测试
缺陷修复
集成测试
验收测试
状态代表测试进展情况
缺陷跟踪
