zoukankan      html  css  js  c++  java
  • 今天开始做主管之如何规范测试团队

    acc211a5fa817de9636e83e41cab99ce.png

    当你来到一个项目不规范的技术团队,你会怎么处理呢?

    问题

    Testing

    流程不规范

    没有需求评审和设计评审,需求经常是业务或者项目经理直接跟开发提,有时候开发自己都不明白需求,糊里糊涂地就要开发,也没有设计评审,开发想怎么设计就怎么设计,代码质量差。

    有时候下游或者上游开发并没有接到需求,然后这边开发完给到测试,测试也一脸懵逼。

    没有计划

    上线时间不是根据开发和测试同学排期和评估来定,而是业务和项目经理说了算。

    开发完了就跟测试同学说一声,有这么个需求,这个需求今晚/这周上线,你测一下,好像测试是个很随意的工作,并且每个任务给过来都说是紧急需求,测试时间也是不够的,导致测试非常被动。

    测试在项目中参与度低

    很多时候没有需求评审,测试同学连业务是谁都不知道,经常是基于开发的讲解进行测试,写不写测试用例也是看自己习惯了,开发同学也不清楚测试同学要测什么,毕竟也没有时间进行测试用例评审(也没有人负责安排)。

    缺乏沟通

    没有每日站会和每周站会,开发和测试同学不会主动反馈进度和风险,即使是当前进度不理想的项目大家也都不提,即使要上线了没测完也不管,反正上线就完事,有时候项目经理会追问测试进度。

    没有共享文档

    所有的测试环境信息、数据库表字段信息、业务说明都是每个人自己保存着自己要用的,大家都不去维护一份公共文档。

    没有输出

    项目完成之后没有总结,出了线上问题大家也不会复盘,无论开发还是测试都没有整理业务文档、记录项目的习惯。

    总而言之,就是十二分不规范。他们可能觉得,本来就够忙了,花时间整这些东西,不是更忙了吗。

    殊不知因为流程的不规范,带来的是更低的研发效率和研发质量。遇到这些问题,可以从哪些方面进行改进呢?

    流程规范

    Testing

    测试进度及计划面板

    可以在一份共享表格中维护,可以是在一块白板里用便利贴跟进,列出目前开发中的、已提测待测试的、测试中的、已完成的任务,并且标明计划提测时间、实际提测时间、计划上线时间等信息,方便管理测试计划和测试进度。

    技术评审

    中大型项目在开发之前需要有技术评审,各端开发都需要参与,尽量避免由一个人决定怎么开发就怎么来。

    提测规范

    达到提测标准时需要发送提测邮件给测试同学,说明改动范围、影响点、自测情况、单元测试覆盖率等。

    测试用例评审

    中大型需求需要在测试前进行测试用例评审,相关的产品和开发都需要参与。

    需求把控

    Testing

    需求实例化

    沟通需求时,测试同学可以将需求用各种形式表现,便于产品、开发之间沟通和确认细节。

    梳理流程图:复杂的交互可以画流程图,方便后面的测试同学理解需求。

    组内需求沟通

    如果是由几个测试同学跟进的大需求,在大家看了需求文档之后安排个小会议室,大家一起头脑风暴一下,由一个人先主讲整个过程,然后其他同学进行补充和提问,达到快速学习和掌握需求的效果。

    快速确认测试点

    如果是时间紧迫的需求,可以几个测试同学到一个小会议室,结合代码改动点快速确认当前实现是否符合目标,是否有逻辑问题,然后结合需求和改动点快速梳理测试点。

    公共点整理:各个重要的模块注意事项和踩坑点汇总成一份各模块checklist,下次测该模块的同学就能尽量少踩坑。

    总之,就是发挥主观能动性,有什么好的实践可以帮助提升测试质量和提高测试效率,就可以去做,最重要的是及时沟通。

    团队成长

    Testing

    月度总结

    每个月测试组内做一次总结,可以分享典型问题,可以提出一些大家觉得待改进的点,也可以随意吐槽。最后将大家提出的点整理好推动落地。

    项目总结

    大项目上线后,组织相关同学进行总结,每个人分享觉得自己做得好和做的不好的地方,总结可以改进的点并推动落地。

    典型问题学习分享

    在月度总结里一起,需要大家提前将各自要分享的问题记录到统一地方,可以是测试中遇到的典型问题或者线上产生的问题。

    业务文档整理

    一般需求上线后第二天比较空闲,这是整理业务文档的好机会,可以整理业务流程,或者相关的sql、操作文档、脚本等。

    业务分享

    每周一个同学在组内做业务分享,可以不需要准备ppt,直接在白板上画,可以分享自己熟悉的一个业务,或者是这周接手的一个业务需求,达到组内知识共享的效果。

    可能有同学会奇怪,为什么都是这么基础这么普通的东西,为什么不做自动化提升效率。

    说说我的想法

    Testing

    一是自动化并不是解决所有问题的万金油,为什么要自动化,当然是到手工测试效率阻塞测试进度的阶段,才需要通过自动化提升测试效率。

    而想要提升效率,应该是先文档化,将知识沉淀下来,然后是脚本化,将重复性的工作自动化,最后是结合基础脚本实现平台化。

    一上来啥也不管就想用自动化测试平台完成自己的KPI并不是一个理智的想法。

    二是,我认为组织目标是要基于当前的矛盾的,每个阶段有每个阶段的矛盾,每个团队当前面临的问题不同,比如需求不清晰、 测试环境不够用、测试环境不稳定、造数据效率太低啦等等。

    那么我们要做的就是基于这些问题一个个推进解决。所以不是在任何情况下都是测试框架测试平台才显得高大上,特别是面对流程不规范的团队,把这些基础的流程做好,就能大大提升大家的工作效率了。

    原文链接:

    https://juejin.cn/post/7018353738062495757

    end

  • 相关阅读:
    Windows SDK编程(Delphi版) 之 应用基础,楔子
    一个小问题引发的论证思考
    Delphi 组件开发教程指南(7)继续模拟动画显示控件
    用PyInstaller将python转成可执行文件exe笔记
    使用 .Net Memory Profiler 诊断 .NET 应用内存泄漏(方法与实践)
    Microsof Office SharePoint 2007 工作流开发环境搭建
    How to monitor Web server performance by using counter logs in System Monitor in IIS
    LINQ之Order By
    window 性能监视器
    内存泄露检测工具
  • 原文地址:https://www.cnblogs.com/finer/p/15579173.html
Copyright © 2011-2022 走看看