仅以此文用来抒发一些对于行业现象的批判。
敏捷是现在十分流行的软件研发模式，并且正在成为业界主流。下图来自于2018年软件测试行业报告，可以看到在受访测试人员中，工作于敏捷或类敏捷项目中的比例已经高达89%。
将测试融入敏捷模式中，根据敏捷项目的模式进行调整，实现“敏捷测试”，是成熟的测试团队必须具备的能力。
在谈论敏捷测试之前，首先要搞清究竟什么是敏捷。
敏捷，汉语名词解释指反应（多指动作或言行）迅速快捷，关键在于快字。也正是由于这一特点，非常适用于小步快跑的现今项目节奏，也使得敏捷得以大行其道。做项目，必谈敏捷，不敏捷项目经理出门都不好意思跟人打招呼。
然而，许多（危言耸听的说，甚至是大多数）项目对于敏捷的理解和应用都是产生了偏差的。对于某些项目组织者而言，敏捷就像是一棵救命稻草，使得他们可以名正言顺的抛弃掉他们认为的那些繁文缛节，自以为是的将团队力量投入到他们认为最有价值的领域中去。这样的敏捷，蔑视流程，蔑视管理，蔑视所有的准备和规划，到头来项目只能是乱成一团。
敏捷是行之有效的理念和模式，但必须被正确的看待和使用。
当我们谈论敏捷，我们到底在谈论什么
有一些理论体系中，会将敏捷和一些常见的软件生命模型并列而谈，认为敏捷与瀑布模型、迭代模型一样是一种“模型”。但笔者认为，与其认为敏捷是一种模型，不如说是一种颠覆性理念。敏捷这一概念所对比的，并不是软件生命模型，而是更基础的，软件研发的组织办法：“软件工程”。
软件产业的发展，经历许多个阶段，从早期的软件开发=编程，到上世纪70年代，逐渐诞生了工程体系。到现在，软件工程已经是行业的一种标准理念了。
我们不妨回过头来问一句，为什么软件的研发要采用“工程”式的组织？
我们不去纠结其名词解释，工程这个词通常的用法在什么场景下面呢？他被用的最多的一个领域可能就是：基础建设“工程”，比如盖房子，装修--典型的工程式管理。
我们可以对比一下软件研发和基建项目的类同性：通过一行一行代码的积累，与一砖一瓦的将一栋建筑搭建起来，是不是非常近似呢？！
于是就如下图所示，我们将软件研发过程与基建工程做了一个类比：
这种类比是非常ok的，确实我们可以按照基建工程的组织形式，将软件研发同样进行工程式管理。到现在为止，“软件工程”已经是我们行业内的标准定义和模式了。
在工程思维导向下，许多“精益生产”领域的理论体系也在被不断的融入软件研发行业内，比如PMP项目管理，比如CMMi成熟度模型，等等。
——————————————————————————分割一下——————————————————————————————————————————
但是，随着社会节奏的加快，业内的人士逐渐发现了工程式管理的弊端。比如，繁文缛节的项目组织、计划、设计阶段所花费的投入，甚至远高于实际的产品生产。
这个时候我们再回过头去审视我们关于软件工程和基建工程的对比，他们真的是一毛一样的吗？
盖一栋房子，我们需要严密的工程规划，设计，需要严格按照计划进行建筑材料的采购，需要严格按照结构设计的要求进行施工。规划和设计中出现的一点不合理，都可能会动摇后续的工作的根基；施工过程中的一点点不严谨，都可能造就成一项豆腐渣工程。
那么软件研发是不是也同样如此？是不是一个产品功能特性，采用A方法完成和B方法完成会产生根本性问题？是不是少写几行代码，就一定会导致产品的崩溃？是不是没有设计图纸，工程师就完全无法开展施工（编码）工作？
你会发现这些问题的答案全部都是否定的，软件研发与基础建设工程绝非完全类同，衡量软件研发的成功与否，甚至只有一条标准：用户的满意。
换一个角度来说，传统工程意义上的软件研发，将软件视作一种待售产品，他与其他的商品生产过程并无二样。那么精益生产的理念，流水线式的生产车间管理也被引入软件研发过程。软件真的与工厂里流水线上生产的产品一样吗？绝对不一样，软件的需求具有高度定制的特性，不同的企业不同的人不同的群体，需要不同的软件，绝非日用产品那般千篇一律。随着理念的更新和升级，现在的业界更多认为，与其说软件是一种产品，软件更是一种服务。用做服务的思想去做软件研发，也是敏捷的出发点之一。
所以从这个角度而言，软件究竟通过怎么样的过程被研发出来，并不重要，重要的是研发出来的软件要符合用户需求。闭门造车，循规蹈矩，工厂车间式的软件研发，已经不能适应当今的许多项目需求。
我们可以看看，敏捷四宣言都在谈论什么：
- 人员交流重于过程与工具（Individuals and interactions over processes and tools）
- 软件产品重于长篇大论（Working software over comprehensive documentation）
- 客户协作重于合同谈判（Customer collaboration over contract negotiation）
- 随机应变重于循规蹈矩（Responding to change over following a plan）
对于这些敏捷宣扬的理念，如果不理解敏捷的上述背景，就会产生应用的偏差。
比如说第二点：软件产品重于长篇大论，强调说复杂的文档不是软件研发的核心，产品本身才是我们的最终目标。指的其实是我们不应该过分追求复杂的文档，指的是文档形式的转变，而不是不要文档！敏捷项目有着自己适用的文档组织形式，比如敏捷需求更倾向于使用用户故事形式，而非传统意义上的PRD。
再比如说第四点：随机应变重于循规蹈矩，强调说不应该死板的遵循计划，而是应该拥抱变化。他谈论的问题核心在于变化的处理和应对，而不是毫无计划，杂乱无章！
比如传统意义上的软件研发，可能耗费一两年一个软件才最终问世，而在这一两年的时间内，这个软件到底是否符合市场定位和用户需求，这一判断是含糊的，因为这个过程中最终用户始终也没有看到软件的成品。而敏捷则强调对于用户需求的强响应，通过引入冲刺周期的形式，将庞大的软件开发过程拆分成为期2-4周的阶段，快速的产出基础产品。快速的将基础产品推向市场和用户，让用户来评判产品的适用度，如果市场满意度低，一个字：改。
拥抱变化，这才是敏捷。
最后总结一下：
敏捷的核心在于灵敏迅捷，在于快速。快速的终极目标不是为了快速而快速，不是为了偷工减料而快速，不是因为你管理能力低下，很多事情你组织不好，所以干脆抛弃这些你没能力做好的事情来达到快速目的。不是因为敏捷所以可以不要需求，因为敏捷所以该做的事情不做，不要以敏捷为借口来达到偷懒的目的，这是无知和无耻的表现！