敏捷测试理论以及实践(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的图作为今天文章的结尾。(未完待续)

本文出自seven的测试人生公众号最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-09-27 05:03:47

敏捷测试理论以及实践(5)的相关文章

敏捷测试理论以及实践(1)

前言: 关于敏捷测试这块内容,本来之前一直想写的,但是自己一直觉得还没法归纳得很好,不过最近有个客户到我们公司来拜访时,也提到了他们公司要把测试这块工作弄好的事情,谈了几个小时,相互交流了一下意见,总算双方都有点收获,所以接下来几天想结合我们公司的实际情况介绍一下敏捷测试的一些相关知识,当然咱的想法也并非很权威啦,仅供参考. 正文: 谈到敏捷测试,可能有些人不一定听到过,不过很多人应该听到过敏捷开发吧,其实从广义来讲,测试也是属于开发过程的一部分,测试完成以后开发过程才算真正完成,所以敏捷测试其

敏捷测试理论以及实践(4)

上面已经谈到了准敏捷测试模式了,离咱们所说的敏捷测试已经无限接近了,但是要了解真正的敏捷测试,还是需要回到敏捷开发上来讲,前面一开始已经说过,敏捷测试严格上来说其实是属于敏捷开发的一部分,所以敏捷开发的价值观也会同样适用于敏捷测试,那么敏捷有哪些价值观呢?总共是五个,分别是简单.沟通.反馈.勇气.谦逊. 光看这五个词,我想大部分人可能会晕乎了,不知所云的,难道敏捷就五个词能概括了?就像电影里出现的武功秘籍一样,一招就一个图,我们看了根本就不知道是啥,人家一看就能炼成神功了. 其实呢,这几个价值观

敏捷测试理论以及实践(6)

2.编码阶段: 完成了需求设计阶段,就要开始进入编码阶段了,虽然说开发与测试需要同步的,但是功能还没做完也没法同步去测吧,不过还是有事做的,就是可以同步开始写测试用例,这个就用到DevTest工具了.DevTest主要用于管理测试用例,以及根据测试用例来进行在不同环境下.不同时间下和不同的范围里进行的手动测试与自动测试,并且可以生成报表供评估测试质量和产品质量. 也许有人有疑问,敏捷测试还需要测试用例?我的答案还是"是"又"不是". 先说"不是"

敏捷测试理论以及实践(7)

5.传统测试阶段 当开发完成了所有的功能点,测试那个时候也差不多完成了这些功能点的测试,我们就会有一个阶段性的最终版给客户评估,让客户看看需要的功能是不是都已经可以了,如果觉得没什么问题,一般情况下就不进行功能添加与更改了.(当然,真的要更改我们还是会欢迎的,不过一般客户也知道,频繁的更改不能保证产品的质量,所以到最后他们一般有不紧急的更改也会要求放在下一个版本里的) 到目前为止,真正意义上的敏捷测试阶段其实已经完成了,要开始进入一些传统的测试了,比如系统测试,性能测试,压力测试等.这些就会用到

敏捷测试理论以及实践(3)

现在先来总结一下到底上面说的模型存在着哪些问题: 1.客户生气地说:这个产品好像不是我们想要的吧!早知你们给我这样子的产品,我才不会下单了,你们也早点跟我说这个产品是这样子,到现在才给我看,浪费我时间,精力,我不买了!(客户到交付后来发现产品与当初他们提的需求不一致,所以很生气,后果很严重) 2.设计团队激动地说:都开发了这么长时间了,你们还要改功能加功能啊,这样子会影响到很多其他功能的,会影响最后发布时间的,而且最后的质量如何,我不能保证.(老兄,我出钱买你们产品的好吧,我想加什么功能改什么功

敏捷测试理论以及实践(2)

所谓的V模型,其实是对瀑布模型的一种修改,也算一个Change吧,详见下图: 由于瀑布模型对于软件的需求分析与设计阶段考虑不足,导致可能会出现严重的设计问题,最后交付到客户手里才会被发现,所以V模型就考虑到这点,针对开发的各个过程都会有相应的测试环节,比如用户需求会对应验收测试,需求分析和系统设计会对应确认测试和系统测试等等(详见上表),这样子起码在交付前会把用户需求方面的问题覆盖到,不太会出现说这个产品不是客户想要的这种问题. 但是缺点也是显而易见的,跟瀑布模型一样,测试过程还是放在了最后环节

应用Visual Studio 2010辅助敏捷测试(上)

敏捷软件开发是近些年来比较热门的话题,<敏捷宣言>四条主要精神和十二条基本准则概括了敏捷开发的基本思想.围绕着这些基本概念和思想,产生了一系列的轻量级方法,如:极限编程.测试驱动开发.Scrum.特性驱动开发等.虽然具体名称.过程和侧重点不尽相同,但是相对于非敏捷的开发方法而言,它们都更强调面对面的沟通.团队不同角色之间的紧密协作.频繁交付新的可用的软件版本.紧凑而自我组织型的团队等.敏捷开发只是提供了一个思想和方法论,而要在实际的工程中正确运用它,并真正显现出它的优点和产生实际的效果,这对于

一起谈.NET技术,应用Visual Studio 2010辅助敏捷测试(上)

敏捷软件开发是近些年来比较热门的话题,<敏捷宣言>四条主要精神和十二条基本准则概括了敏捷开发的基本思想.围绕着这些基本概念和思想,产生了一系列的轻量级方法,如:极限编程.测试驱动开发.Scrum.特性驱动开发等.虽然具体名称.过程和侧重点不尽相同,但是相对于非敏捷的开发方法而言,它们都更强调面对面的沟通.团队不同角色之间的紧密协作.频繁交付新的可用的软件版本.紧凑而自我组织型的团队等.敏捷开发只是提供了一个思想和方法论,而要在实际的工程中正确运用它,并真正显现出它的优点和产生实际的效果,这对于

敏捷测试中,我们的测试组织应该如何建设

但如何真正在项目中做到敏捷,除了方法论之外,还有各种外部条件的制约.而现实是很多研发团队只注重了方法论的学习,而没注意组织结构应该如何变化才能适应敏捷测试的需要.有的人可能会说,敏捷强调的不是人人都应该是开发和测试吗?但这只是在理想情况中.真实项目中,肯定还是存在测试和开发的分工的.所以本文想谈谈在敏捷测试中,我们的测试组织应该如何建设,才能合理将工作进行分工,充分发挥组织内部每个人的长处.即在敏捷测试环境中,我们应该用什么样的人,去做什么样的事,才能获得最大的效率. 近些年,在软件项目中非常流