质量度量落地的注意事项和思考

后台有同学留言问了这样一个问题：
想在团队内推动质量度量落地，对每版本迭代的交付质量有更好的评估，但没有太多的实践经验，有没有什么落地方法或者注意事项。
首先聊聊质量度量本身，即质量需不需要度量？
答案显而易见：质量需要度量，而且需要持续的度量！为什么呢？
我们所从事的软件测试工作(随着技术不断发展，现在也叫作质量保障)，工作对象就是软件系统。经过需求设计、需求评审、技术设计、代码开发、测试验证、上线发布等多个环节，才能保障这些软件的最终交付质量。
这一整套复杂的流程，实际上就是将不确定性(需求)转化为确定性(具有严密逻辑的软件系统)的过程。确定性，需要一定的衡量标准来评估它是否满足预期的设计，因此需要一定的数据来进行度量。
而持续度量的原因，是业务和技术本身就处在一个不断变化发展的状态，需要持续的度量和评估，才能保障软件系统的质量长期处在一定的水准之上，满足用户需要和保障业务目标达成。
质量度量的本质，是具体的定量，而非抽象的定性。

其次聊聊质量度量的注意事项，这些注意事项是我个人结合工作经历和实践总结的经验教训，仅供参考。
质量保障是一个体系化和长期建设的过程，而质量度量作为最重要的一环之一，在落地过程中需要持续跟进和优化。
质量保障不仅仅是QA同学的事情，因此质量度量也不能只关注测试维度。
度量指标需要根据团队特性和业务具体情况来制定，并且需要评估是否合理，而不是强行制定强行执行。
质量度量是为了保障最终交付质量能更好的满足用户需要，进一步达成业务目标，而非为了度量而强行度量。
质量度量并非一蹴而就，在软件不同的生命周期和团队成熟度阶段，度量的范围和执行严格程度要灵活变通。

最后，分享一些我对于软件质量度量的一些思考。
1、不要为了度量而度量，找到合适的度量对象很重要。
比如听一些同学说他们的质量度量指标，就有首次测试用例执行通过率，以及累积测试用例执行通过率。
这两个指标是为了解决什么问题？如果只是看到别人有，那我也要做，只是浪费时间和资源。而且你花大力气去做，大概率也得不到整个技术团队的认可。
2、度量指标一定要和具体的问题挂钩，否则指标没有意义。
最常见的，测试用例覆盖率，测试用例通过率。这个度量指标的作用是什么，要解决什么问题。
比如提测冒烟通过率必须100%，否则证明了主流程存在block，影响测试进度。这个度量指标要解决的是可测性和测试进度，提高从编码到测试环节的交付产出物质量。
3、度量的指标和数值一定要和直接干系人达成一致。
还是以冒烟提测通过率为例，如果研发团队不认可，怎么办？
很多时候测试团队没有太大话语权，没办法影响到研发团队。这个时候要学会迂回策略。即如果冒烟提测通过率不达标，导致了什么结果，这个结果的风险是什么，会带来什么不好的影响。然后向更上一层汇报，暴露风险。
4、度量指标和数值不能解决问题，只能证明发生了什么。
设置度量指标和衡量的数值后，要明确一点：度量产生的数据不能直接解决问题，而是证明产生了什么结果。
要分析数据背后的原因，什么原因导致了这个结果，这个原因的风险和对交付质量有什么不好的影响，然后才是拿着数据和分析的结果去推动改进。
5、落地质量度量有很多前置条件，质量度量不是单一存在的。
举个例子，通过度量缺陷数量和用例数量以及对应的百分比，来评估每版本的编码质量。
这个逻辑没问题，但不是单单搞个对比数据就可以的。缺陷&用例需要和对应的代码分支关联，代码又要和需求关联。否则只有数据，没有因果关系，证明不了问题，也解决不了最本质的需求不完善和代码质量不高的问题。
6、质量度量是一个复杂的技术工程，更需要大量的沟通和协作。
工作真正要解决的是人的问题，技术不存在难点，难点在于思路，以及说服其他人配合你行动。
想清楚再行动，先从小范围试点，从最痛的点开始，这样推进的动力更大。

最后，聊点题外话，我写了一个付费订阅技术干货合集，内容如下图所示：

图片
这个合集分为三大模块，共计10篇文章，一次订阅，终身免费，目前已完结。内容主要涵盖性能测试、自动化测试、以及测试技术专项治理。
本技术合集的内容，整合我过往所有技术文章，从中梳理和抽取了精华内容，加上我近几年大量的咨询和实践案例，不废话，直接上干货，后期不排除新增内容和答疑部分。内容亮点如下：
从零到一的技术落地经验
从一到十的技术体系建设案例
从十到百的技术发展和演进路径
写作本付费合集的目的：解决大家在技术层面存在的缺陷，为大家打开更广阔的技术视野，帮助广大测试同学建立完善的技术知识体系，以便在职场和个人职业发展中有更好的竞争力。
如何订阅付费合集？关注公众号，点击公众号主页下方的技术干货标签，即可订阅。或者点击付费订阅技术干货合集也可以订阅。