存在的问题
流程不规范
确实必要环节的评审。没有需求评审和设计评审,需求经常是业务或者项目经理直接跟开发提,有时候开发自己都不明白需求,糊里糊涂地就要开发,也没有设计评审,开发想怎么设计就怎么设计,代码质量差。
有时候下游或者上游开发并没有接到需求,然后这边开发完给到测试,测试也一脸懵逼。
没有计划
项目时间计划没有依据实际情况。上线时间不是根据开发和测试综合排期评估来定,而是业务和项目经理自己定上线时间。
不按照正规流程进行闭环。开发完了就跟测试同学说一声,有这么个需求,你测一下,啥时候上线。。。好像测试是个很随意的工作,并且每个任务给过来都说是紧急需求,测试时间也是不够的,导致测试非常被动。
测试在项目中参与度低
很多时候没有各个环节评审,测试同学连业务是啥都不知道,经常是基于开发的口头说做了啥进行测试,写不写测试用例也是看自己习惯了,开发同学也不清楚测试同学要测什么,毕竟也没有时间进行需求评审、技术评审和测试用例评审。
项目组缺乏沟通
缺少每日和每周站会,各个环节人员不会主动反馈项目进度和存在的风险,即使是当前进度不理想的项目大家也都不提,即使要上线了没测完也不管,反正上线就完事,有时候项目经理会追问测试进度。
缺少必要环节的文档共享
各个环节没有抽出专门时间整理相关问题,大多数当面沟通完事,所有的测试环境信息、数据库表字段信息、业务说明都是每个人自己保存着自己要用的,即便有少数文档,没有人去维护以及更新文档。
缺少复盘总结
项目完成之后没有总结,没有人组织复盘会议,没有形成最终的闭环。无论开发还是测试都没有整理业务文档、记录项目的习惯。避免以后项目踩相同的坑。
殊不知因为流程的不规范,带来的是更低的研发效率和研发质量。遇到这些问题,可以从哪些方面进行改进呢?
流程规范
测试进度及计划
在管理工具中或者,在一块白板里用便利贴跟进,列出目前开发中的、已提测待测试的、测试中的、已完成的任务,并且标明计划提测时间、实际提测时间、计划上线时间等信息,方便管理测试计划和测试进度。
需求评审、技术评审和测试用例评审
项目启动后,首先进行需求评审,有必要进行多轮需要评审;项目在开发之前进行有技术评审,各端开发都需要参与,尽量避免由一个人决定怎么开发就怎么来;之后进行测试用例评审,把控用例测试点是否全部有遗漏。相关的产品和开发都需要参与。
提测规范
严格按照规定的流程规范提测到测试人员,比如,测试单、邮件等,记录版本情况,并且说明改动范围、影响点、自测情况、单元测试覆盖率等。
需求把控
需求实例化
沟通需求时,测试同学可以将需求用各种形式表现,便于产品、开发之间沟通和确认细节。
梳理流程图:复杂的交互和逻辑,产品需画流程图,方便后面的测试同学理解需求。便于项目组人员快速理解。
组内需求沟通
如果是由几个测试同学跟进的大需求,在大家看了需求文档之后安排个小会议室,大家一起头脑风暴一下,由一个人先主讲整个过程,然后其他同学进行补充和提问,达到快速学习和掌握需求的效果。
快速确认测试点
如果是时间紧迫的需求,可以几个测试同学到一个小会议室,结合代码改动点快速确认当前实现是否符合目标,是否有逻辑问题,然后结合需求和改动点快速梳理测试点。
公共点整理:各个重要的模块注意事项和踩坑点汇总成一份各模块checklist,下次测该模块的同学就能尽量少踩坑。
总之,就是发挥主观能动性,有什么好的实践可以帮助提升测试质量和提高测试效率,就可以去做,最重要的是及时沟通。
团队成长复盘
月度总结
每个月测试组内做一次总结,可以分享典型问题,可以提出一些大家觉得待改进的点,也可以随意吐槽。最后将大家提出的点整理好推动落地。
项目总结
大项目上线后,组织相关同学进行总结,每个人分享觉得自己做得好和做的不好的地方,总结可以改进的点并推动落地。
典型问题学习分享
在月度总结里一起,需要大家提前将各自要分享的问题记录到统一地方,可以是测试中遇到的典型问题或者线上产生的问题。
文档整理输出
上线后,各个环节人员整理相关文档并上传共享。可以整理业务流程,或者相关的sql、操作文档、脚本、技术设计文档、测试计划、测试报告等。