多测师-多培养一些优秀的测试工程师
网站地图 |   收藏本站   |   

17727591462

软件测试之质量的管理

发布日期:2022-08-01 09:15:52 作者:多测师 浏览次数:

  核心的思路是对缺陷做分析和考核,并做研发流程中主要问题的梳理和改善。

  常常做的事情可以从下面几个方面来看(这里会是主管以上的人来负责):

  1. 做质量数据的统计和分析

  收集的数据很多,常见的有:

  - 外网的bug情况,包括事故,及影响的程度

  - 测试阶段的bug数量,分布(按系统,团队,开发个人),严重程度,bug的类别等维度

  - bug的横向跨团队和系统的对比,纵向的和历史情况对比

  - 版本发布的情况,代码变更行数的情况

  从这些数据的收集中就能发现很多问题,比如问题集中在哪里,哪些模块,哪些人,哪些类别等等,以及有没有改善。

  2. 问题的追溯和对于开发的考核

  这个方面也许有一些争议,但是我还是觉得这个是一个很重要的方法。光靠观念和自觉是不够的,必需要有一定的反馈机制,就好比交规一定是配合着扣分和罚款等手段,否则记录闯红灯有什么意义呢?而且现实的来说,这些方法起到约束的作用,也是一种心理暗示,要做自己做的东西负责,也便于养成好的习惯。

软件测试之质量的管理

  通常的考核指标涉及这些方面:

  - 编译失败次数的考核

  - 外网事故和bug的数量

  - 测试阶段的bug,特别是基础功能bug和严重bug

  粗略的列了这么多,其实可以有很多,比如配置文件改错的情况,漏提测文件的次数等等。

  对于bug方面其实也是一样,如果开发在乎(或者被迫在乎)外网bug或者被测试发现的bug数量,他写代码的时候一定会更仔细,也会做些简单的自测,让提测的质量更高,提高了整个研发系统的效率,同时也是提升了质量,因为quality must be built in。

  我个人的经验,作为测试人员几乎同时面对过两个开发团队,一个有上述的考核,一个没有。表现出来的版本质量和对质量的关注完全不一样,而且前者也并没有出现开发和测试的对立,以及测试不敢提bug等负面的情况。

  3. 对于测试的考核

  除了对于开发的考核,同样也有对于测试的考核,这样也更加的公平。

  测试的考核通常考虑下面的指标:

  - 漏测:绝对数量或者漏测率

  - 版本的工作量和测试效率

  - 发布延期的情况

  如果测试有这样的压力,也需要不断努力去发现更多的bug。

  说起考核,总有人觉得这不符合智力劳动的情况,或者互联网的作风,其实不太理解为什么会这么觉得,放眼望去,有什么工作不被考核呢,sales要背quota,为什么软件开发和测试不能对自己的工作的质量负责呢?当然,具体的指标如何去定才更合理那是另一个要去考虑的。

  换个角度来看,适当的压力(不应该导致焦虑和扭曲的做法),其实是让一个人表现最好的状态。

  4. 推动开发的自测

  这个问题一向是个老大难问题。愿意自测的开发团队你不用太多的推动,不愿意做的推动也很难,或者你无法判断他有没有做自测。而且这方面,通常取决于开发负责人的观念和态度。

  如果是介于之间的,我们可以做一些事情,比如:

  - 统计测试阶段的bug中,属于开发可自测发现的比例。通过这个可以看有多少bug是不应该到测试阶段的,以及横行纵向的对比。当然这个标准要自己拿捏。

  - 给出一个自测的checklist。开发在提交前要完成这个list并正式的给出报告。这个方式我们曾经在一个项目中用过,效果不错,基本功能都通过这个保证了,前提是开发负责人认可。

  - 有一套自动化验收的用例,可以挂接到自动部署之后或者daily build。前提是我们的自动化要足够的问题,效果才会好。

  这个阶段除了业务测试的努力,也体现出了QA的价值。这里的QA是指质量管理,有的地方叫SQA,专注在质量度量和研发流程的管理上。

  到这个阶段,发现事情顺了很多,质量也有更大程度的提升,并有改善的趋势。

如需了解更多测试技术信息请关注:https://www.duoceshi.cn/jswz/深圳多测师软件与技术服务有限公司


查看更多 >>

推荐阅读