码迷,mamicode.com
首页 > 其他好文 > 详细

产品质量体系——如何度量产品质量?

时间:2019-12-01 00:36:48      阅读:211      评论:0      收藏:0      [点我收藏+]

标签:提升   冥想   错误   工作量   频率   质量   接下来   影响力   生产   

        测试经理小陈,新入职了一家公司,部门总监老王很重视产品质量,希望小陈的加入,能给产品质量带来提升。小陈呢,在这样的背景下,被满怀期待地走马上任了。过了三个月,老王就问小陈:小陈啊,最近产品质量怎样啊?提升了没有啊?小陈呢,内心咯噔一下,心想,我擦,老板查岗了,没有数据告诉老板质量提升了,是不是证明我来和没来,没啥区别哈。我也好歹兢兢业业干了三个月呀,总不能让老王觉得我没有价值啊,一定想办法告诉老王,产品质量提升了,即使没有提升,也得告诉他,我已经定位到问题了已经调整中了不是。

  小陈苦思冥想啊,怎样证明产品质量呢?老板关心什么呢?经过灵魂的几大拷问以后,明白了,老板关心的是 产品是否会出问题?

       那我得证明,我来了以后,产品出问题的次数少了呀,那么,接下来的事情是:怎么证明呢?

       小陈想到,如果上线以后发现的bug比以前更少了,是不是可以证明呢?小陈巴拉巴拉翻出了近三个月,每次上线以后直接或者间接收到的 prod bug信息,发现,9月 4个,10月4个,11月竟然5个。小陈脑子瞬间蒙了,尼玛,不但不能证明自己质量好了,岂不是证明自己更坏事了?但是自己进来以后三个月越来越忙了啊,有时候都加班到10点11点才能回去。

  小陈是一个矜矜业业的小陈,经过一番冷静的思考以后呢,觉得,不能这样,我们还是要看看每个月迭代的工作量的。小陈就翻出了,这几个月开发过程中bug总数,发现,9月份 210;10月,320;11月,570。开发这几个月的开发质量,怎么辣么差,我得和老板说道说道。小陈转念一想,一来盲目告状,不利于团队协作,第二个,开发的质量真的会连续几个月忽高忽低吗?我们不能以开发过程中的数据说明问题。他琢磨着,如果开发中bug总数多,是不是出现prod bug的概率也就高呢,小陈还是一个理智的小陈。

  

月份 9月 10月 11月
prod bug数量 4 4 5
开发过程中bug数量 210 320 570
prod bug/开发过程中bug数量 1.9% 1.25% 0.88%

  

  于是乎,小陈罗列了以上的一个表格,算了下prod bug/开发过程中bug数量,按照每个月的这个趋势,这个结果,小陈还是挺满意的。他心满意得地给这个公式取名为:bug逃逸率。

    所谓bug逃逸率,就是迭代过程中,未发现的bug的概率。

    bug逃逸率=prod bug/开发过程中bug数量。

  小陈,志得其满地想,终于可以和老板汇报了。这个时候,有同事反馈,产品访问出现50X错误。影响线上所有用户了,小陈的心啊,翻江倒海,数据说不上话,事故是真的啊,别想了,先解决问题吧。和devops的同事一起一顿研究,发现数据库磁盘满了,没有及时扩容,devops那里也没有提前收到告警。赶紧的吧,devops的同事一顿骚操作,问题解决了。看来,光看bug数量也是不行的,事故频率也得考虑进来哈。看来,质量工作光靠我一个人的力量是不行的……

  小陈再次陷入了沉思,脑子盘算着几个问题:

  1. 生产bug的统计,谁去统计呢?回忆杀不靠谱哈,要是我没统计到,别人发现了的怎么办?打脸哈
  2. 老板对我期望很高,质量提升,偶尔杀出个事故来,咋整?一个重大抵得上100个prod bug的影响力了

 小陈,还是个想做事情的小陈,我们未完待续吧~

 

产品质量体系——如何度量产品质量?

标签:提升   冥想   错误   工作量   频率   质量   接下来   影响力   生产   

原文地址:https://www.cnblogs.com/ilazysoft/p/11964420.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!