测试经理如何规范测试团队(测试管理篇)
Posted 软件测试君
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了测试经理如何规范测试团队(测试管理篇)相关的知识,希望对你有一定的参考价值。
当你来到一个项目不规范的技术团队,你会怎么处理呢?
问题
流程不规范
没有需求评审和设计评审,需求经常是业务或者项目经理直接跟开发提,有时候开发自己都不明白需求,糊里糊涂地就要开发,也没有设计评审,开发想怎么设计就怎么设计,代码质量差。
有时候下游或者上游开发并没有接到需求,然后这边开发完给到测试,测试也一脸懵逼。
没有计划
上线时间不是根据开发和测试同学排期和评估来定,而是业务和项目经理说了算。
开发完了就跟测试同学说一声,有这么个需求,这个需求今晚/这周上线,你测一下,好像测试是个很随意的工作,并且每个任务给过来都说是紧急需求,测试时间也是不够的,导致测试非常被动。
测试在项目中参与度低
很多时候没有需求评审,测试同学连业务是谁都不知道,经常是基于开发的讲解进行测试,写不写测试用例也是看自己习惯了,开发同学也不清楚测试同学要测什么,毕竟也没有时间进行测试用例评审(也没有人负责安排)。
缺乏沟通
没有每日站会和每周站会,开发和测试同学不会主动反馈进度和风险,即使是当前进度不理想的项目大家也都不提,即使要上线了没测完也不管,反正上线就完事,有时候项目经理会追问测试进度。
没有共享文档
所有的测试环境信息、数据库表字段信息、业务说明都是每个人自己保存着自己要用的,大家都不去维护一份公共文档。
没有输出
项目完成之后没有总结,出了线上问题大家也不会复盘,无论开发还是测试都没有整理业务文档、记录项目的习惯。
总而言之,就是十二分不规范。他们可能觉得,本来就够忙了,花时间整这些东西,不是更忙了吗。
殊不知因为流程的不规范,带来的是更低的研发效率和研发质量。遇到这些问题,可以从哪些方面进行改进呢?
流程规范
测试进度及计划面板
可以在一份共享表格中维护,可以是在一块白板里用便利贴跟进,列出目前开发中的、已提测待测试的、测试中的、已完成的任务,并且标明计划提测时间、实际提测时间、计划上线时间等信息,方便管理测试计划和测试进度。
技术评审
中大型项目在开发之前需要有技术评审,各端开发都需要参与,尽量避免由一个人决定怎么开发就怎么来。
提测规范
达到提测标准时需要发送提测邮件给测试同学,说明改动范围、影响点、自测情况、单元测试覆盖率等。
测试用例评审
中大型需求需要在测试前进行测试用例评审,相关的产品和开发都需要参与。
需求把控
需求实例化
沟通需求时,测试同学可以将需求用各种形式表现,便于产品、开发之间沟通和确认细节。
梳理流程图:复杂的交互可以画流程图,方便后面的测试同学理解需求。
组内需求沟通
如果是由几个测试同学跟进的大需求,在大家看了需求文档之后安排个小会议室,大家一起头脑风暴一下,由一个人先主讲整个过程,然后其他同学进行补充和提问,达到快速学习和掌握需求的效果。
快速确认测试点
如果是时间紧迫的需求,可以几个测试同学到一个小会议室,结合代码改动点快速确认当前实现是否符合目标,是否有逻辑问题,然后结合需求和改动点快速梳理测试点。
公共点整理:各个重要的模块注意事项和踩坑点汇总成一份各模块checklist,下次测该模块的同学就能尽量少踩坑。
总之,就是发挥主观能动性,有什么好的实践可以帮助提升测试质量和提高测试效率,就可以去做,最重要的是及时沟通。
团队成长
月度总结
每个月测试组内做一次总结,可以分享典型问题,可以提出一些大家觉得待改进的点,也可以随意吐槽。最后将大家提出的点整理好推动落地。
项目总结
大项目上线后,组织相关同学进行总结,每个人分享觉得自己做得好和做的不好的地方,总结可以改进的点并推动落地。
典型问题学习分享
在月度总结里一起,需要大家提前将各自要分享的问题记录到统一地方,可以是测试中遇到的典型问题或者线上产生的问题。
业务文档整理
一般需求上线后第二天比较空闲,这是整理业务文档的好机会,可以整理业务流程,或者相关的sql、操作文档、脚本等。
业务分享
每周一个同学在组内做业务分享,可以不需要准备ppt,直接在白板上画,可以分享自己熟悉的一个业务,或者是这周接手的一个业务需求,达到组内知识共享的效果。
可能有同学会奇怪,为什么都是这么基础这么普通的东西,为什么不做自动化提升效率。
说说我的想法
一是自动化并不是解决所有问题的万金油,为什么要自动化,当然是到手工测试效率阻塞测试进度的阶段,才需要通过自动化提升测试效率。
而想要提升效率,应该是先文档化,将知识沉淀下来,然后是脚本化,将重复性的工作自动化,最后是结合基础脚本实现平台化。
一上来啥也不管就想用自动化测试平台完成自己的KPI并不是一个理智的想法。
二是,我认为组织目标是要基于当前的矛盾的,每个阶段有每个阶段的矛盾,每个团队当前面临的问题不同,比如需求不清晰、 测试环境不够用、测试环境不稳定、造数据效率太低啦等等。
那么我们要做的就是基于这些问题一个个推进解决。所以不是在任何情况下都是测试框架测试平台才显得高大上,特别是面对流程不规范的团队,把这些基础的流程做好,就能大大提升大家的工作效率了。
下面是配套资料,对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!
最后: 可以在公众号:伤心的辣条 ! 免费领取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享!,其中包括了有基础知识、Linux必备、Shell、互联网程序原理、mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
学习不要孤军奋战,最好是能抱团取暖,相互成就一起成长,群众效应的效果是非常强大的,大家一起学习,一起打卡,会更有学习动力,也更能坚持下去。你可以加入我们的测试技术交流扣扣群:914172719(里面有各种软件测试资源和技术讨论)
喜欢软件测试的小伙伴们,如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一键三连哦!
好文推荐
转行面试,跳槽面试,软件测试人员都必须知道的这几种面试技巧!
面试官:工作三年,还来面初级测试?恐怕你的软件测试工程师的头衔要加双引号…
一个测试经理的分享:我是如何管理测试团队的
很多刚从测试人员转向测试管理岗的同学,肯定会有很多疑惑,不知如何下手
且一时观念无法转变
到底该如何管理测试团队?
很多同行已经写过N多类型专题文章
今天老徐主要分享自己的经验,以及老徐是如何管理测试团队的
仅个人经验分享
可参考、欢迎点评
--正文--
测试管理,范围很广
带1-2人也是管理
带几十人也是管理
但是管理方法肯定会不一样
今天分享10人左右的测试团队,老徐是如何管理的
1.
首先,根据业务情况,或者项目情况,拆分成几个测试小组;
每个组,有一个测试负责人
老徐只需直接管理每个组的负责人就ok
(注:每个人的最佳管理人数是有限的)
2.
充分的放权
所有各小组负责人对各自负责的小组质量负责
有问题让随时找我沟通
而且老徐也会每周进行1-2次的分享
以及每周一次的周会沟通
每周所有成员的周报
3.
问题分析
老徐喜欢分析漏测的问题
对于各类漏测的问题,重点分析
对于测试同学这是最快的成长方式(知道马云的湖畔大学吧,专门分享失败经验,从失败中吸取经验是最快的成长方式,如何避免重复出现类似问题)
每个测试同学,工作过程中都会出现漏测的情况,发布出去的版本存在各种质量问题,但是如果同类重复多次出现,就得批评了
4.
充分的自由
老徐只关注结果,所有测试同学对结果负责
如果能高效高质的完成工作
老徐不太会关注你过多
如:上班偶尔聊聊天,早上晚点到,临时有事提前走几个小时,都ok
(前提:管理者所在公司给你放权,你有说话权;很多公司管理非常严格,老徐不太赞成那种工厂式的管理方式)
5.
自动化保障
所有的接口、构建、部署,全部自动化实现
对人的依赖性小
6.
招聘、人员补充
根据当前团队成员情况、以及产品项目情况,招聘互补型的成员
对于测试管理者,首页必须要了解团队中每个成员的详情情况
每个人的优势、性格、擅长测试的类型
--结束--
以上纯属老徐个人观点,欢迎交流
如果你想实时与老徐交流你的观点,分享你的经验,像老徐咨询你存在的各种问题
加群《软件测试:邀你同行》(339611752)与老徐实时交流
分享、成长、收获!
以上文章老徐原创,未经允许勿转载!
以上是关于测试经理如何规范测试团队(测试管理篇)的主要内容,如果未能解决你的问题,请参考以下文章