质量度量落地的注意事项和思考
后台有同学留言问了这样一个问题:想在团队内推动质量度量落地,对每版本迭代的交付质量有更好的评估,但没有太多的实践经验,有没有什么落地方法或者注意事项。
首先聊聊质量度量本身,即质量需不需要度量?
答案显而易见:质量需要度量,而且需要持续的度量!为什么呢?
我们所从事的软件测试工作(随着技术不断发展,现在也叫作质量保障),工作对象就是软件系统。经过需求设计、需求评审、技术设计、代码开发、测试验证、上线发布等多个环节,才能保障这些软件的最终交付质量。
这一整套复杂的流程,实际上就是将不确定性(需求)转化为确定性(具有严密逻辑的软件系统)的过程。确定性,需要一定的衡量标准来评估它是否满足预期的设计,因此需要一定的数据来进行度量。
而持续度量的原因,是业务和技术本身就处在一个不断变化发展的状态,需要持续的度量和评估,才能保障软件系统的质量长期处在一定的水准之上,满足用户需要和保障业务目标达成。
质量度量的本质,是具体的定量,而非抽象的定性。
其次聊聊质量度量的注意事项,这些注意事项是我个人结合工作经历和实践总结的经验教训,仅供参考。
质量保障是一个体系化和长期建设的过程,而质量度量作为最重要的一环之一,在落地过程中需要持续跟进和优化。
质量保障不仅仅是 QA 同学的事情,因此质量度量也不能只关注测试维度。
度量指标需要根据团队特性和业务具体情况来制定,并且需要评估是否合理,而不是强行制定强行执行。
质量度量是为了保障最终交付质量能更好的满足用户需要,进一步达成业务目标,而非为了度量而强行度量。
质量度量并非一蹴而就,在软件不同的生命周期和团队成熟度阶段,度量的范围和执行严格程度要灵活变通。
最后,分享一些我对于软件质量度量的一些思考。
1、不要为了度量而度量,找到合适的度量对象很重要。
比如听一些同学说他们的质量度量指标,就有首次测试用例执行通过率,以及累积测试用例执行通过率。
这两个指标是为了解决什么问题?如果只是看到别人有,那我也要做,只是浪费时间和资源。而且你花大力气去做,大概率也得不到整个技术团队的认可。
2、度量指标一定要和具体的问题挂钩,否则指标没有意义。
最常见的,测试用例覆盖率,测试用例通过率。这个度量指标的作用是什么,要解决什么问题。
比如提测冒烟通过率必须 100%,否则证明了主流程存在 block,影响测试进度。这个度量指标要解决的是可测性和测试进度,提高从编码到测试环节的交付产出物质量。
3、度量的指标和数值一定要和直接干系人达成一致。
还是以冒烟提测通过率为例,如果研发团队不认可,怎么办?
很多时候测试团队没有太大话语权,没办法影响到研发团队。这个时候要学会迂回策略。即如果冒烟提测通过率不达标,导致了什么结果,这个结果的风险是什么,会带来什么不好的影响。然后向更上一层汇报,暴露风险。
4、度量指标和数值不能解决问题,只能证明发生了什么。
设置度量指标和衡量的数值后,要明确一点:度量产生的数据不能直接解决问题,而是证明产生了什么结果。
要分析数据背后的原因,什么原因导致了这个结果,这个原因的风险和对交付质量有什么不好的影响,然后才是拿着数据和分析的结果去推动改进。
5、落地质量度量有很多前置条件,质量度量不是单一存在的。
举个例子,通过度量缺陷数量和用例数量以及对应的百分比,来评估每版本的编码质量。
这个逻辑没问题,但不是单单搞个对比数据就可以的。缺陷 &用例需要和对应的代码分支关联,代码又要和需求关联。否则只有数据,没有因果关系,证明不了问题,也解决不了最本质的需求不完善和代码质量不高的问题。
6、质量度量是一个复杂的技术工程,更需要大量的沟通和协作。
工作真正要解决的是人的问题,技术不存在难点,难点在于思路,以及说服其他人配合你行动。
想清楚再行动,先从小范围试点,从最痛的点开始,这样推进的动力更大。
版权声明: 本文为 InfoQ 作者【老张】的原创文章。
原文链接:【http://xie.infoq.cn/article/f92e7cb2cda9d9e3acce356f5】。文章转载请联系作者。
评论