微信号:grzlwx

介绍:光荣之路官方资讯

聊聊测试管理(管事篇)

2016-03-01 23:05 光荣之路

吴老师要开课了!测试开发精品班!

管理:管人+管事。
说到管理,其实就是团队,没有团队,就谈不上管理。个人理解,对个人而言,更多应该是计划,而非管理。做管理的时间并不长,或者说很短,可能很多地方理解的有问题。写这篇文章也是为了能更多的与大家交流,也是记录下在目前这个阶段我的理解。(本文均以在创业型公司工作为背景),全篇分为管事篇跟管人篇。
管事篇
一、测试的工作流程
关于这个点,其实网络上一搜一大堆,大体都差不多,需求分析,测试计划,设计测试用例,评审用例,执行测试,缺陷管理,定版,发布。但是,我认为作为一个测试leader,在一个创业型公司,并不是出一个这样的流程这么简单。我觉得更多应该考虑的是适合公司的。在我制定我们团队的测试流程时,与我们的项目经理,架构师甚至产品经理都有过很长时间的沟通,测试活动离不开产品,开发,所以在测试的工作流程中,应该包括如何去产品,开发更高效的去协作。下面讲讲我整理的测试工作流程。

1、需求分析

黑盒测试离不开需求分析,所有的测试都是基于需求,如果对于需求的理解不够透彻,测试的质量也就可想而知。所以在这个阶段,我会花很大量的时间去做。我团队的需求分析主要包括:两图一文档。
两图:业务流程图,思维导图。
一文档:需求分析文档。
业务流程图,是对于需求从流程(整体)去理解。思维导图,是对需求所包含的各项功能点去理解。需求分析文档,是对思维导图中的功能点去发散成为测试点。这样下来,一个需求所表达的内容,基本不会漏掉。而更高层次的隐性需求,就需要对业务有着很深的理解,这点可以在工作中慢慢去引导团队成员去做。流程上很难去控制。

2、测试计划

网络上的测试计划,都是一个文档,一大堆形式上的东西,可能对于大公司而言,有这个必要,我目前所见识的,基本都没有必要。
我认为测试计划主要给出以下几点:
(1)、测试类型:黑盒测试,接口测试,UI自动化测试,接口自动化测试,性能测试等等
(2)、测试时间:需求分析起止时间,设计测试用例的起止时间,执行测试的起止时间
(3)、测试执行人:创业型公司由于人员少的情况,很可能以项目(模块)划分测试负责人,也可以根据设计和执行来划分测试负责人
一个测试计划,有这三点,我个人认为就可行了。

3、测试用例

关于设计测试用例,可能很多在创业型公司工作过的小伙伴会说,时间很紧,压根没时间来做这个事。
这一点,我用了两个月做了一个调研,前一个月不写测试用例,大家就按照自己的思路去测试;后一个月,严格写测试用例,执行测试集去测试。调研结果是:前一个月在测试开始时,测试速度稍微快点,在进入测试中后期,测试速度就很慢很慢,因为常见点已经测试完了,测试工程师自己都不知道哪些东西测试过了,哪些还没?哪些没有问题,哪些还有问题?不能很直观的去管控。后一个月在开始时,由于写测试用例的时间,速度会稍微慢点,但是在中后期,测试效率明显比前一个月要好很多,测试工程师对于项目的把握也更清楚。两者整个花的时间基本差不多。质量就更不用说了,肯定后者更有保证。
探索性测试,我觉得在业务能力以及测试经验都很充足的情况下,可以结合编写测试用例,去执行测试。一味的追求探索性测试,其实对于大多数测试工程师来讲,很难。
目前,我的团队是,测试工程师编写好测试用例,先组内评审,然后导入到QC,测试人员根据QC测试集去执行测试,而我也能很直观的把控测试进度,以及当然存在的问题。

4、测试用例评审

用例评审很重要,毕竟测试工程师也是人,也会有很多点是想不到的,所以用例评审就是一个查漏补缺的环节。用例评审不是找人茬,而是在这个过程中,补充测试思路,提升测试质量。
年前,这一项,我们没有做,因为当时我们的测试工程师写的用例还达不到评审的水平,所以只是组内评审。目前已经启动用例评审。效果还待观察中。
测试用例评审方法:
(1)、提前邮件提醒评审相关人员(开发负责人,产品负责人,测试负责人,项目经理等),附件上测试用例。
(2)、1-2天后,组织用例评审会议,由于事前有看过需求跟用例,所以会议时间不建议很长,只要是查漏补缺,每个人都会有一些测试思路,也会发现已有的测试用例的不足。
(3)、根据会议记录,将没有考虑到的点维护成测试用例。定版。
定版后的测试用例,就可以用来执行测试了。

5、缺陷管理

缺陷,最重要的是,清晰明了的说明问题,重现步骤,以及如何解决。
效率的提高在于细节,缺陷管理工具上写的不明了,也可以通过实时沟通来解决,但是沟通就需要时间,如果缺陷管理工具上,写的很清晰明了,这沟通的时间成本就节省了。
一个缺陷就是一个用例,这个思想很重要,我经历的公司,对于缺陷都是放在管理工具中,缺陷解决后,关闭,就没有然后了。其实每一个缺陷都是一个优秀的用例,这些用例你可能已经写了,也可能没有,而没有的话,就需要维护到测试用例中去,下次执行时,你就多预防一个点。

6、验收测试

通常,通过测试的功能就会准备上线。但是上线前,还需要产品或者运营,来验收需求。功能实现是否满足需求,有没有未考虑到的功能等等。产品或者运营做验收测试时,我会给一个EXCEL文档,作为他们记录问题的LIST,每天跟我反馈下进度跟结果。如果有缺陷,再安排时间去解决。如果有需求上的缺陷,会定会议评审,在这次发布修改,还是下次发布修改。最后,上线与否,需要他们的确定。

二、测试时间

1、争取测试时间
创业型公司,产品版本迭代快,周期紧,往往压缩的是测试时间。而测试质量在一定程度上,与测试时间成正比,所以这点很矛盾。
测试时间需要争取,因为项目时间很紧,资源更多的用于开发,上线时间确定后,基本上离上线时间只有2天时间才开发结束,才交付测试。而这么短的测试时间,要保证测试质量很大,并且可能还需要大量加班。而测试时间的争取,又需要测试质量作为依据。那么怎么来争取测试时间呢?我认为是这样的:
(1)、尽量在开始时,哪怕加班也要做好质量保证,之后在争取时间的时候,可以尽量拿质量作为理由来说;
(2)、平常要多跟项目经理,架构师等聊聊产品质量,输送质量意识,并多讲讲测试的重要性,不是每一个开发或者负责人,对于测试很重视的,尽管现在测试行业在快速发展。
(3)、就是在测试时间上,坚决不让步。上线后,产品出现问题,很多时候,会让测试背锅,当然也有开发的原因,但是大家的想法是:这个问题怎么没有测试到?这个时候,你再说测试时间不够,意义就不大了。

2、安排测试时间
测试时间的安排,需要根据测试人员本身能力定。能力强的,当然需要的时间短。大体上而言,我对于测试时间的安排如下:
(1)、模块内(模块间交互少)的功能,需求分析时间和设计测试用例的时间为1天,执行测试的时间为2天(主要是缺陷修复时间),最后验收时间为半天。
(2)、模块间交互多的功能,需求分析和设计测试用例各1-2天,执行测试时间4-5天,最后验收时间为1天。
(3)、系统级的功能需求,需求分析3天及以上,设计测试用例时间2-3天,执行测试时间一周以上,最后验收时间为2-3天
主要策略是,需求分析的时间得保证,这个时间不能挤,毕竟这是测试最重要的部分。设计测试用例的时间可以稍微挤挤,这块最主要的时间是需要写文档。测试时间多考虑缺陷修复时间,测试一轮下来可能很快,但是缺陷修复的时间就可能很久。最后需要验收时间,产品或者运维对于该功能的验收,看是否满足产品需求。

三、测试进度与质量

1、测试进度
测试计划确定后,接下来就是测试进度的把控了。进度的把握不是实时的要求测试工程师反馈,也不是自己想了解的时候就去问一下。需要有这么一个规则,既可以直观的查询到目前的测试进度,又可以接受测试工程师的反馈。而我们团队的规则如下:
1、使用项目管理工具:Teambiton,任务板上有每一个测试工程师在这次发布前的任务,每一个任务都有详细的测试时间,能明了直观的看到任务的执行情况。
2、执行QC测试集:QC测试集,是基于测试用例的执行,每一个用例的每一个步骤都有执行状态,这样在测试过程中,就能实时的查看到当前测试的进度。这个最为准确。有没有偷懒,或者是否是应付式的工作都能看出来。
3、每天下班前,都会将今天的测试情况反馈给我。这一点准备改良,定为每天早上5-10分钟站会。每一个人都需要讲讲昨天干了什么,今天准备干什么。时间长了,站会可以提高整个团队的效率。
4、每天早上跟每天下班前,都需要检查一次缺陷管理工具,查看今天已解决尚未验证的缺陷是否已经处理完了。
如果出现测试进度很慢,跟预期严重不符,会先跟相关测试工程师讨论,是预期时间不够,还是测试工程师本身的问题,还是开发工程师的问题。这个时候就是需要测试leader来解决了。找到相应的问题并解决它。
如果出现测试进度过快,也需要去确认,防止为了赶进度而忽略质量的情况。

2、测试质量
行业内有一句话:测试不能保证软件质量。我认为,虽然我们不能保证软件质量,但是我们可以保证测试质量,尽量提高软件质量。
测试的质量,是测试活动最重要的一环,所有之前的一切都是基于提高测试质量为目标的。那么如何提高测试质量呢?
(1)、充足的测试时间。并不是时间越长越好。
(2)、全面的测试需求分析。
(3)、充分的测试用例设计。
(4)、测试人员的能力(管人篇详细聊)
(5)、做好验收测试。
(6)、风险控制
等等。

四、线上跟踪

我一直都认为,不管测试多么精确,到线上后,都会存在问题。只是说测试可以尽量去减少这样的情况发生。
如果产品上线后,出现问题,怎么处理?
第一时间,在测试环境中,重现。能重现,则找相应的开发工程师解决,再评估上线时间。如果不能重现,就直接找项目经理,评估解决办法。
而一般而言,出现问题后,责任我会担着(这是一种得人心的方法),事后会跟相关的测试工程师去探讨出现这个问题的原因,是由于他自己引起的,就总结为什么,争取别在同一个地方跌倒两次,对于他而言,是一种成长和进步。

结语
以上仅仅是个人的理解。希望大家能多探讨。

(作者:山丘的测试之道 来源:http://www.cnblogs.com/weientesting/p/5227572.html)

公益传播测试知识、技能与正能量!感谢作者!
分享测试生活,思考测试人生!欢迎投稿!
文章图片来自网络,如有侵权请见谅,请联系我们妥善处理。
735821166@qq.com


光荣之路
软件测试培训


官网:www.gloryroad.cn

微信公众号:gloryroadtrain

性能测试QQ群:415987441
测试招聘QQ群: 203715128
自动化3群QQ: 371211499

Python群:457561756


 
光荣之路 更多文章 今天晚上的 linux 公开课- Awk 编程 7月28日(今天)晚上的 linux 公开课- shell编程 8月4日(今天)晚上的 linux 公开课- shell编程 9月1日(本周一)晚8点半,光荣之路Web自动化系列基础课—javascript第二讲 推荐本好书《与机器赛跑》
猜您喜欢 膨胀比预想更快? 最新研究可能重写宇宙学 TNT沙龙第22期:全心全意为创业者服务— ChinaBangAwards2014年度评选巡展 数人云 | 一场属于 Docker&Mesos 的夏日欢乐颂 产品不快,你就死定了! 【学习】Mac OS X 应用程序开发笔记