如何用指标去度量bug本身的质量情况
如何用指标去度量bug本身的质量情况
作为测试同学我们会经常苦恼如何使用一些指标来度量版本或产品的质量情况，近些年来比较主流的声音可能变成了如何使用指标来度量研发效率，以及如何在不影响线上质量的前提下提高研发效率，降低交付周期，不过今天我却听到了不同的声音，无意中浏览到一篇文章，讲的是如何去度量测试同学提的bug本身的质量情况。
先上图，先看看在这形形色色的图表下隐藏有哪些通用指标。
Bugs Integrity Level
就是上面那4个圈，颜色越绿就代表bug的完整性越好，也就是提出的bug的质量越高。
Dev Efficiency - Bugs per resolution with drill across
中间位置左边的那几个柱状图，这里汇总了下面一些信息。
- 绿色部分：开发解决了的bug，也就是这些bug被开发接受，并被测试验证过了
- 非绿色部分表示的是被开发拒绝的bug，其中拒绝理由有下面4种
- Works as designed (WAD)：这不是bug，产品设计就是如此
- Ir-reproducible：无法复现
- Environment：环境问题，嗯，是不是很亲切
- Duplicated：重复的问题
Dev Efficiency - % Rejected
中间部分靠右的4个圈，按季度统计了bug的被拒绝率，颜色越深拒绝率越高。
Average time in status - bug
bug在特定的生命周期停留的平均时间，不过作者也说了，他们仅将其视为一种晴雨表，把这个当成硬指标，因为并非所有状态都掌握在 QA 手中，而且创建这个bug的人其实并不总是对bug的所有状态负责。用过jira的同学可能会这个图表会有些印象。
Bugs integrity - number of missing fields
这部分是对字段不完整的bug的统计。我们先看一下作者公司的提bug模版。
- Description：bug描述
- Steps to Reproduce：重现步骤
- Expected results： 预期结果
- Actual results：实际结果
这个图表展示了所有创建了的bug数量以及缺失具体字段的bug数量，看上去还是很清晰的。不过我会有一些疑问，如果1个bug这些字段都缺失了，那么这个bug会不会被重复算到每一种具体的缺失分类中去？另外为什么这些字段不能设置成必填？
Bugs integrity - % perfect bugs
这里展示了字段完整的bug比例，也就是完美的bug的比例。
# UI bugs without visual attachment
如果某个bug跟ui相关，那么我们会期望提bug的时候带上截图或者录屏，这里就是展示的没有放图的ui bug比例，如果这个比例高于10%那么bug的质量就是异常的。
unnecessary ping pong
这个指标很有意思，结合现在比较主流的微服务架构来看，每个具体的业务服务都按照一定规律被打散拆小，每个服务高度自制，服务之间基本是相互隔离的，开发人员很多情况下只对自己负责的服务负责。但是测试人员却是站在整个业务的高度去提bug，他可能只知道某个功能不可用，但不一定知道是哪个具体的微服务不可用，比如测试同学发现外卖系统中无法下单，这个bug可能是鉴权微服务出了问题，也可能是订单微服务存在异常，正常工作的系统总是类似的，系统不正常的时候同一个表象背后的原因可能会是五花八门。
上面这个指标的意思就是测试人员在提出bug的时候直接指出是哪个微服务出了问题，这样就能减少不必要的沟通成本，提升bug修复的效率。这里猜对了就加分，猜错了就减分。
总结
总的来说这些指标还是比较实在的，特别是猜微服务那部分挺有新意，另外这个面板是使用jira的eazyBI插件来实现的，在统计缺字段的bug时还用到了ScriptRunner插件。当产品质量趋于稳定或者工作中没有亮点的时候，大家可以试着祭出这些指标，因为有指标就有kpi，有kpi就有产出了吧。
