多数人对测试的理解大概是：
- 在需求阶段，可以针对需求提出个人的见解，找出其中可能的逻辑缺陷
- 在开发阶段，可以实现UI、接口的自动化，来节约回归成本，以及针对线上的日常巡检脚本
- 在测试阶段，可以覆盖整个系统进行测试，找出潜在的缺陷，更好一点地，能够为开发提供修改缺陷的思路
- 在发布之后，能进行线上的验收，然后进入下个迭代
这也是目前比较普遍的测试活动。不过其中存在一些问题：
- 一般而言，在普遍的UI、接口的自动化中，会不可避免地存在高度的重复性，原因是：都是基于业务模拟手工执行。
- 在测试阶段，总会有一些漏测情况不断发生
- 发布后，由于各种原因导致发布不顺利，验收不通过
基于以上及其他的一些痛点，敏捷测试的概念应运而生，主要提倡测试团队是一个赋能团队，为产品、开发、运维赋能，其中涉及到的能力如下：
其中涉及的名词一言半语说不清楚，暂时不展开来说，以上的技能目的都是为团队完成快速的、稳定的、可预期的交付。