51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 8966|回复: 20
打印 上一主题 下一主题

[原创] 聊聊测试管理(管事篇)

[复制链接]
  • TA的每日心情
    开心
    2016-7-21 11:07
  • 签到天数: 37 天

    连续签到: 1 天

    [LV.5]测试团长

    跳转到指定楼层
    1#
    发表于 2016-2-29 15:13:42 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    管理:管人+管事。
    说到管理,其实就是团队,没有团队,就谈不上管理。个人理解,对个人而言,更多应该是计划,而非管理。做管理的时间并不长,或者说很短,可能很多地方理解的有问题。写这篇文章也是为了能更多的与大家交流,也是记录下在目前这个阶段我的理解。(本文均以在创业型公司工作为背景),全篇分为管事篇跟管人篇。
    管事篇
    一、测试的工作流程。
    关于这个点,其实网络上一搜一大堆,大体都差不多,需求分析,测试计划,设计测试用例,评审用例,执行测试,缺陷管理,定版,发布。但是,我认为作为一个测试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)、风险控制
    等等。

    四、线上跟踪

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

    结语
    以上仅仅是个人的理解。希望大家能多探讨。
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏15
    回复

    使用道具 举报

  • TA的每日心情
    无聊
    2018-5-10 09:16
  • 签到天数: 172 天

    连续签到: 2 天

    [LV.7]测试师长

    2#
    发表于 2016-2-29 16:58:57 | 只看该作者
    冒烟测试        回归测试(1、bug回归  2、用例回归  3、功能回归)
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    昨天 09:11
  • 签到天数: 936 天

    连续签到: 3 天

    [LV.10]测试总司令

    3#
    发表于 2016-3-1 09:27:21 | 只看该作者
    不错的分享,支持下~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2016-3-1 15:08:55 | 只看该作者
    我刚入测试行业一年,准备向测试主管方向发展,看了您的文章,感觉自己需要努力的东西还有很多。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2016-7-21 11:07
  • 签到天数: 37 天

    连续签到: 1 天

    [LV.5]测试团长

    7#
     楼主| 发表于 2016-3-2 17:18:13 | 只看该作者
    黑盒测试 发表于 2016-2-29 16:58
    冒烟测试        回归测试(1、bug回归  2、用例回归  3、功能回归)

    这两项,貌似没写上去,
    冒烟测试:    在开发提测后,会进行冒烟测试,主要做的是流程测试跟场景,确认该版本是否达到可测程度。
    回归测试:    新需求的加入,就会执行回归测试,上线前的回归主要做的是功能回归。还在测试阶段的回归,基本每一个版本都会执行用例回归跟BUG回归。
    谢谢提醒。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2016-7-21 11:07
  • 签到天数: 37 天

    连续签到: 1 天

    [LV.5]测试团长

    8#
     楼主| 发表于 2016-3-2 17:19:25 | 只看该作者
    lsekfe 发表于 2016-3-1 09:27
    不错的分享,支持下~

    谢谢。
           刚开始做分享,欢迎多来交流与知道啊,管理员
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2016-7-21 11:07
  • 签到天数: 37 天

    连续签到: 1 天

    [LV.5]测试团长

    9#
     楼主| 发表于 2016-3-2 17:20:26 | 只看该作者
    wenxiping 发表于 2016-3-1 15:08
    我刚入测试行业一年,准备向测试主管方向发展,看了您的文章,感觉自己需要努力的东西还有很多。

    加油,一起努力吧。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    昨天 09:11
  • 签到天数: 936 天

    连续签到: 3 天

    [LV.10]测试总司令

    10#
    发表于 2016-3-2 17:31:14 | 只看该作者
    山丘的测试之道 发表于 2016-3-2 17:19
    谢谢。
           刚开始做分享,欢迎多来交流与知道啊,管理员

    客气了,如果愿意长期在论坛进行冒泡的话。可以申请版主哦!并且添加我的QQ:2385139409 聊聊!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    2016-8-31 11:25
  • 签到天数: 9 天

    连续签到: 1 天

    [LV.3]测试连长

    12#
    发表于 2016-3-31 14:18:08 | 只看该作者
    很不错的分享,收藏了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2017-5-23 11:47:23 | 只看该作者
    管人是个很心累的事 ,手下有好几个项目,有两个项目自己扛,另个项目交给其他人,这个项目如果别人做的很好,就会出现一方独立造反迹象,就感觉有点边疆造反的局面。处理不好,就闹独立。而自己其实之前扛的两个项目,已经心力憔悴。作为老大来讲,我觉得此时唯一要做的就是锻炼身体,提升心智
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2017-5-23 16:10:47 | 只看该作者
    同时想跟楼主探讨下怎么管人
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2017-7-7 17:56:00 | 只看该作者
    先说下,觉得楼主写得很好,另外想问楼主公司做的是什么类型的产品,测试用例是什么形式的,颗粒度怎么把握
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2017-9-14 16:57:50 | 只看该作者
    对于互联网公司,敏捷开发的模式,测试计划其实并不是很看重,我觉得更重要的是测试用例的设计和测试用例的评审2个方面。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情

    2018-4-10 14:27
  • 签到天数: 11 天

    连续签到: 1 天

    [LV.3]测试连长

    17#
    发表于 2017-10-20 15:33:40 | 只看该作者
    写得非常好,学习并收下!
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-1-10 16:48
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    18#
    发表于 2018-1-5 17:27:20 | 只看该作者
    探讨探讨如何管人,目前管理一个近10人的团队,水平也都参差不齐,有些人在公司比我还久,感觉管理起来深有压力
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2018-2-10 21:04:06 | 只看该作者
    及时审计很重要,目前负责3个产品的测试管理工作,人力15+也还好
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2018-8-2 10:29
  • 签到天数: 5 天

    连续签到: 1 天

    [LV.2]测试排长

    20#
    发表于 2018-2-12 17:11:48 | 只看该作者
    目前正是需要这些东西,来得及时
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-4-25 09:03 , Processed in 0.081064 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表