敏捷测试理论以及实践（5）

敏捷测试理论以及实践（5）

　以前在《结合工具来实现敏捷开发》这篇文章中，我已经谈到了我们公司目前的开发情况，在这里也不再重复介绍了，反正主要就是用 TechExcel的 DevSuite 系统来进行管理整个流程。至于很多人可能会问，既然敏捷了为啥还要用工具，其实我是这么想的，敏捷开发/测试，如果对于简单的项目而言，用工具反而会效率下降，因为就这么几行代码，这么几个功能，一下子就可以弄好了，弄个工具反而浪费时间。

　　但是对于稍微大的项目而言，可能不用工具就没法很好地管理项目了，比如说好了，一个团队在一个迭代周期中做了10个功能，测试人员一天发现了40个Bug，但是修的人（由于部分人还在做功能）每天最多只能修20个，那剩下的20个Bug怎么办，当然是延迟到下一天修了，一个迭代周期往往是一周到二周，假设两周好了，如果每天都能多余20个Bug的话，就累积了200个未修的Bug，假设没有缺陷管理工具的话，我这些Bug可能只用Excel文档管理一下，Excel对于单个用户而言，保存信息其实做得很不错，报表也很Ok，但是想想这么多开发和测试需要打开同一个Excel文件，做查看，做更新，我相信Excel数据会被搞乱，而且Excel没法做跟踪，没法设置流程，也就是比如说我想知道这个Bug经历过几个状态，经历过几个人的处理，我应该是没法找到的。

　　所以工具有用么，我觉得还是有用，对于大中型项目，既然想用敏捷，我还是建议用工具，不然的话，这个敏捷最后肯定会变成不敏捷的。 就像乘坐公交车一样，如果就是100米的路，我劝你还是走路（敏捷）算了，因为公交车还要起步、停车和等红绿灯了，也许你走得都比它快；如果是10公里的路，您当然会选择公交车（工具）。对于敏捷而言，因为是有很多迭代周期组成，每个迭代周期其实相当于一个100米，但是很多迭代周期组合在一起就变成了10公里了。真正的敏捷，它只是一种指导思想，没规定你必须怎么做（也就出现各式各样的实现方式），所以，在正常的工作中，我们需要根据每个公司的实际情况来搭配符合你们实际情况的敏捷模式。

　　大家在百度上，只要搜索“敏捷测试”，我相信可以找到一大堆的内容，有概要的，有详细的，仔细看看，大家会发现很多人认为敏捷肯定是这样子的，那样子是不对的，当然大家对于“这样子“的描述又都不是太相同，分析一下，无非就是两种原因，一种纯粹是自己瞎想的，可能稍微有点底子，但是没实际用过，就按自己的想法，乱分析一番；另外一种就是真正在用的，所以就用自己公司的情况来解释一下敏捷。当然，我其实也是结合自己公司的情况在说敏捷，所以我不会苛求大家一定要采用我的理论，只是希望大家能从我的文章里发现一点对你们来说有用的知识，那我就很开心了。

　　好了，闲话少说了，不管您有没有理解为什么要用工具，我还是继续下去了（有问题可以私聊）。

　　对于TechExcel的DevSuite，以前也介绍过，也一直用到现在，感觉挺好用，不过在这里也不多介绍了，就给个图和然后把我们会用到的产品做个交代，不然之后万一提到某个产品，大家可能不知道是啥了。

　　其中对于敏捷测试而言，需要用到的主要是以下三个产品：

　　1、DevSpec：需求管理，用于测试人员（设计测试人员）检查功能的设计

3、DevTest：测试管理工具，用于管理测试用例，以及用测试用例来生成测试计划并且实施测试（包括自动化测试）

　　这三个产品可以集成在一起用，也可以分开单独用，当然我们是集成起来用的。

　　接下来我就按照测试的实际流程来介绍一下敏捷测试在我们公司的具体实现情况。

　　1、需求设计阶段：

　　我们公司也是开发产品的，主要是开发CRM方面的产品，和其他软件企业也一样，我们每个版本的发布首先是需要先收集客户需求开发相应功能、自己研发出新功能以及查看研究并超越竞争对手的功能。

　　这部分的工作主要是在DevSpec进行，DevSpec是主要用来管理需求和分配需求让开发去开始做的，它会对每个功能（不管是客户的，自己的，或者研究竞争对手得出的）新建一个条目项，每个条目都会有自己的属性，包括标题，负责人，状态等，反正你想加什么属性都可以自定义的。然后负责人登录系统就可以看到分配给他的条目，他处理完了就必须把状态改到下一个状态，并且分配到适当的其他负责人。对于测试而言，我们设置有一个状态叫做“测试审核”状态，一般一个需求点到了这个状态，咱们设计测试人员就会去处理这个需求，处理的方式，一般就是从原始的文档入手，去看看现在的设计是不是符合原始的文档，如果有出入的话，他就会去和设计人员交流一下，然后把这个条目打回“需要重新设计”状态，设计人员弄完就会重新更改状态，最后测试人员审核通过后，就可以进入“待开发“状态了。

　　这里强调一点，在这个阶段，所谓的设计测试人员，并不一定必须是专职的，他可能是项目经理或者是其他人，但是他一定是一个有能力来判断设计思路是否符合要求并且有权力让设计人员重新去设计的人。

　　这就是需求设计阶段，测试人员要做的事情。下面贴个DevSpec的图作为今天文章的结尾。（未完待续）