也谈“敏捷测试”--《全程软件测试》试读

最近一段时间，“敏捷测试”成为了一个热门词汇，我的朋友、包括学生也会来问我，什么是敏捷测试？究其原因大概是因为敏捷开发这一概念的火热。看了朱老师这本书的试读章节，让我也对敏捷测试有了更深一步的了解，那么我也顺着试读中的内容，以我第一次开展的“敏捷测试”做一个简单阐述。

第一次开展敏捷测试是在我刚进入测试领域不久，在一个小型公司的小型项目组中应用了“敏捷”这样一种思维。那首先我要说这次的敏捷尝试是彻底失败的，而且我相信像我们这样失败的例子绝不仅仅是个例，各位看官可以继续向下了解。当时的团队共有六个人，一个PO，负责user story的整理，sprint的制定；一个PM，负责整个sprint的计划和任务分配；三名开发人员以及我。然而最终的形态是什么呢？变成了一个类似敏捷的瀑布式流程；由po作为需求人员，整理需求，pm进行任务的分配，开发人员只管闷声写代码，而我，则作为最后一个测试环节，在要“持续的交付给客户”前进行该版本的验收测试以及上一版的回归测试。唯一保留下来的就是敏捷里的“每日站立会议”，以及没有任何文档记录的传统。

这样一个“伪敏捷”的流程里是否有真实存在的意义？我想答案几乎是no，反而是无休止的会议、没有文档记录但又逐渐缺少交流让整个流程中走了更多弯路。后来当我真正完成了一个敏捷流程后，回过头来总结这次失败的历程，发现了大概如下几点：

一、就像朱少民老师在书中提到的，敏捷测试要强调“自动化测试”，没有自动化，又何来敏捷，怎样持续的交付让客户满意的软件？拥抱需求变化，也是要依靠完善的自动化测试包括单元测试，否则所谓拥抱需求变化，只是空谈。

二、敏捷强调交流，因为很少有工作文档产出。而往往在最初进行敏捷的时候，热情犹在，交流更频繁些，而逐渐的，大家感觉不到交流的意义，所以敏捷便成了空谈。

三、测试驱动开发的思想。换言之就是单元测试是一切的基础，而不管开发人员也好，测试人员也好，在我们项目当时都不具备或者不愿意去做“额外的”单元测试工作。结果是什么？每次提测就出现很多问题，修复这些问题占据了大量的时间。“敏捷”又从何而来？

除了提到这三点，其实还有很多问题存在，在这儿我只想举这个例子告诉所以同行，无论是PO、PM、开发还是测试，都要记得“敏捷”不是挂在口头上，也不是保持几个会议什么的就可以搞定的，而是一种思维观念。敏捷是大势所趋，但是也需要充分的条件才能开展。