关于质量标准化的思考和实践

简介：最近部门在推质量标准化，通过质量标准化，推动质量内建，从而提高研发部门的交付质量，作者深度参与其中，并在推进过程中总结了一些经验以及思考，在此通过以下定义、共识、实践三个大方向和大家分享一下。

作者 | 静艺
来源 | 阿里技术公众号

最近部门在推质量标准化，通过质量标准化，推动质量内建，从而提高研发部门的交付质量，我也深度参与其中，并在推进过程中总结了一些经验以及思考，在此通过以下定义、共识、实践三个大方向和大家分享一下。

一 定义

1 质量标准化

何为质量标准化？用个不太恰当的比喻，大家都知道工厂的流水线作业，每个位置上的人或者机器要做什么都是提前规范好、定义好的，流水线上的商品从原材料到成品经过的都是同一套流程，因此成品间的质量不会相差太远。研发流程和流水线作业有一定的相似性。我们希望通过标准化各条业务线的研发流程，以做的比较好的业务线作为标准样板间，规范出一套标准化的流程，并适用到其它业务线，从而使各条业务线都能进行高质量的交付。

2 质量内建

不少研发团队的同学都认为质量都是靠测试同学去守护的，会认为产品出现了质量问题，是测试的锅，这是对测试工作和质量保障的一种狭隘的认识。测试同学是质量的守护神，可是质量不能只靠测试同学在最后一环去兜底。想要给用户交付高质量的产品和体验，必须是在研发流程各个环节都遵守质量规范，在需求评审、方案设计、开发、自测环节上的产品、开发、测试同学都要有质量意识并严格执行质量规范，这就是质量内建。

3 交付质量

交付质量包含系统质量和产品体验两部分。系统质量指的是系统的功能完备性、系统的稳定性和健壮性，产品体验是指客户使用此产品时是否有丝滑的体验。

二 共识

要让研发流程中的各个角色都愿意去践行一套统一的标准和规范，必不可少的条件是各个角色意识形态上的统一。只有团队的思想一致了，标准和规范才能被推进并落实。在推动 ICBU 跨境资金-国际结算团队标准化建设的过程中，我们团队从上到下首先在以下观点下达成了高度统一。

1 质量不只是测出来的

在知乎上看到针对“质量是被设计出来的，还是被测出来的”问题有一个讨论，觉得写的挺好的，从不同角度分析了这个命题，我把它摘抄出来，针对“质量之道”的本源之争，大家的发言很踊跃，我摘抄了几个具有代表性的：

A同学：我认为质量是设计出来的，在设计上考虑的各种非功能质量数据，都会落地到代码中。设计的优化会不断的驱动系统质量的优化。
B同学：我认为质量是测试出来的，设计的东西可以避免已知的问题，但在实际测试的过程中，还是会发现其他未考虑到的问题，例如兼容性问题，你能提前通过设计预防吗？所以测试发现问题，问题驱动质量提升。
C同学：听完B同学的发言，我更坚信了质量是设计出来的。在不断的BUG驱动下，我们打补丁式做出来的系统，质量会更好吗？打补丁解一时之急，而后续系统性的设计、重构、升级，才是提升质量的关键点。所以...
D同学：如果站到产品层面，我们会怎样去定义产品好不好？在我们定义产品好坏的质量模型里，很可能会包含软件研发相关的非功能质量属性(ISO9126)，可能会包括产品舆情、竞品对比中挖掘出的东西。例如，我们去定义一款内容推荐产品的好坏，除了“内容不重复”、“多样性”等维度外，“是否支持分享”、“是否支持点赞”也会成为质量好坏的评判标准，新功能上线、满足需求，用户就会认为产品好。我们的认知会不断升级，“好”的标准也会有更高的要求。用户无时无刻不在使用、测试、反馈，让质量不断变好。

2 既要、又要、还要、且要

上述的四位同学的观点，代表了不同的质量理念和追求：

1. 谋而后动的观点：无论是对需求的二义性分析、对设计中UML图的流程分析、时序分析、状态分析，都是希望能够磨刀不误砍柴工、降低成本。A同学说得对。
2. 探索式测试的观点：无论是保证在设计变成代码的过程中是否100%的完成翻译，还是在测试的过程中受到启发认为应该写下更多的逻辑代码