zoukankan      html  css  js  c++  java
  • 测试工作效率低思考和改进

    引子

      汇总统计了一下项目组近期测试项目实际工作量与基线工作量的对比,发现一个严重问题。就是工作效率特别低下。下面简单列举一下几个项目预期工作量和实际工作量以及时间耗费严重的地方、项目简要背景。

      1、B版本测试。版本预期工作量15人天,实际耗费工作量在30人天。更为严重的是测试人员并没有因为测试周期延长和工作量投入加大而测试的更轻松,反而是测试期间晚上加班严重,参与测试人员测得还极其难受。有一个背景提前说明,该版本是从同测试部其他项目组第一次交接给我们项目组,另外参与B版本测试的测试人员对手上测试项内容不熟,第一次执行,此为前提。

      2、S专项测试。预期工作量3人天,实际耗费工作量6人天。中间也是各种加班。对测试人员来说,该项内容也是新东西,但是对项目组来说,该项目是相对成熟的验证内容。

     3、已知问题的重复又重复的咨询、确认、沟通。虽然单次耗时不多,但是架不住频率太多。

      测试人员加班多,活干的还不爽,工作量产出与工作时长严重不成正比,自己也在思考这些工作现象和如何改进,否则如果这样状态长期下去肯定会出现人心浮动,身心烦躁、离职、转岗等等问题。。

    效率低突出的几个问题

      1、测试人员接手新项目,没有好用(容易理解、无歧义、有图文指引、详细FAQ)的文档。拿到一个文档不好用,理解费尽也无法Step by Step执行。可能也不知道谁熟悉这一块,知道谁熟悉这一块的人正好又忙的不可开交,三言两语跟你说完了你还是云里雾里,又只能回去继续埋头看,时间就悄悄过去了。过两天测试内容要交付了,活没干完,靠,加班。。烦躁

      2、已知问题反复沟通、确认。A问B解决,C不知道该问题,又问D,D不知道又问A,A可能没记录时间长了忘记了又问B。来回循环特别耗时,看着好像挺不可能的,实际在项目组工作中很常见。有时候就是这种小的不能再小的问题阻塞你工作大半天。过程中问问题的人很郁闷(就这P大点问题搞半天),被问的也很郁闷(咋天天问,我活也干不完啊)。大家都郁闷

     3、返工。举几个例子,环境切换后发现少了一个指令数据没有收集,切换回来。半天过去了。切换前发现某个测试项没有验证切换回来。测试报告写作时发现过程需要截图发现忘记保留,加班从新测试一遍收集一下。累不。烦不。站着旁边看我都觉着累、烦。

     4、习惯于手工操作。比如上百条的命令他可以一个个写,几十个指令的修改他可以一个个改。太可怕了。。明明可以写个脚本一会会可以搞定的,就算不会写,随便组内找个小伙伴帮忙搞两下也就解决了。但是好像习惯了,还觉着很努力。。可能不是常态,但是见过不少了

     5、还有其他的,工具不好用、文档找不着、文档不成体系,遇到问题找不到FAQ等等。。

     6、策略问题。这个可能得专门说了。。不再这展开。

      这些问题不知道在大家项目组是否存在或者是否是突出问题,这里应该还与项目区人员业务、技术成熟度有关,恰巧的是我们当前部门、项目组新人太多了。。可能不是问题的问题都成了大问题。。

    效率低问题改进

      影响测试效率低的问题上面也简单罗列了。不能光吐槽,总得想办法解决啊,起码让自己或者和自己一块干活的少加点班啊。

     1、梳理收集组内现有经验文档,形成知识体系。特别是经常搞的工具使用、专项验证常规特性验证、复杂特性验证等。文档一定要清晰、易懂、规范、能多截图就一张别少。能把点击菜单按钮路径写清楚就写完整。为什么是经常搞的,第一优先级高,常用。另外,统计观察过程发现,影响测试效率低最明显的就是这些常搞的内容。另外,整理完后发布在论坛上,随版本测试实时刷新。知会组内同事。如果组内同事都勤于刷新这些内容,文档和FAQ就会非常详细。另外,还有一个好处,就是可以知道谁搞过相关的事情,咨询问题时就不用来回绕了。。直接找到相关人员解决问题。

     2、多总结,随手记,多分享。上面说的是成体系的,这里主要是随手记一些文档,FAQ。写完可以分享在自己博客、论坛甚至发到工作群里都可以。尽量不要都记在自己电脑上,一个自己可能不好找,后面就忘记了。。另外一个,别人就没法共享你的劳动成功,资源浪费了。。好记性不如烂笔头,多总结,随手记,多分享。与己方便,与人方便。

     3、工具开发与维护。定期维护常用测试工具,让它更好用,不影响测试。定期收集工具需求,开发。。用工具提升测试效率,让工具替人干活,这就是自动化最大的价值。所以,要尽量多思考,多想想自己手上哪些工作可以通过工具替代的。。不要埋头手工搞,不是手工作业的时代了。。

     4、个人技能。这个重点就是要看个人了。。针对自己的手上工作有意识的去总结、拓展、去思考、去分享知识。业务和技能越强,依赖外部的机会就会少些,干活自然效率就会高很多。。

     5、培训。这个实际上是好办法办法,但是去年上半年做了半年培训 实际效果并不好。大家都只是挂着听听。互动也不好,下来就忘记了。。可能是项目太忙,可能是大家没有真实经历某些测试项时并不愿意主动花这个时间去学习,我有时候不愿意参加原因是因为一个是我没有太多时间提前了解,培训时听不懂。。可能是培训形式和方法不太对,这个需要再思考一下

    最后...

      上述的问题其实在很多项目组都经历过,都很普遍,改进方法也都很简单、很老套。只不过在新人多的部门和项目组暴露的更为明显。目前改进的事情如知识体系建立、FAQ整理,常用工作开发和维护都已经在进行中了。。希望工作效率可以上一个层次,大家少加班,身心愉悦

  • 相关阅读:
    IOS 开发 网络发展史(基础知识)
    加密详解
    IOS对接支付的流程
    App混合开发浅谈
    swift语法100
    2015年最新Android基础入门教程目录第二章:Android UI(User Interface)详解(已完结 40/40)
    2015年最新Android基础入门教程目录第一章:环境搭建与开发相关(已完结 10/10)
    Reactive开发
    tensorflow 安装
    Mask RCNN笔记
  • 原文地址:https://www.cnblogs.com/linyfeng/p/11026339.html
Copyright © 2011-2022 走看看